Thesis Nelson Gama - Integrating EA and ITSM

UNIVERSIDADE DE LISBOA
INSTITUTO SUPERIOR TÉCNICO
Integrating Enterprise Architecture and
IT Service Management
NELSON FERNANDO PINHEIRO DA GAMA
Supervisor: Doctor MIGUEL LEITÃO BIGNOLAS MIRA DA SILVA
Thesis approved in public session to obtain the PhD Degree in
Information Systems and Computer Engineering
Jury final classification: Pass with Merit
Jury
Chairperson: CHAIRMAN OF THE IST SCIENTIFIC BOARD
Members of the Committee:
Doctor JOÃO PAULO ANDRADE ALMEIDA
Doctor FERNANDO MANUEL DA COSTA BRITO E ABREU
Doctor JOSÉ LUIS BRINQUETE BORBINHA
Doctor MIGUEL LEITÃO BIGNOLAS MIRA DA SILVA
2014

UNIVERSIDADE DE LISBOA
INSTITUTO SUPERIOR TÉCNICO
Integrating Enterprise Architecture and
IT Service Management
NELSON FERNANDO PINHEIRO DA GAMA
Supervisor: Doctor MIGUEL LEITÃO BIGNOLAS MIRA DA SILVA
Thesis approved in public session to obtain the PhD Degree in
Engenharia Informática e de Computadores
Jury final classification: Pass with Merit
Jury
Chairperson: CHAIRMAN OF THE IST SCIENTIFIC BOARD
Members of the Committee:
Doctor JOÃO PAULO ANDRADE ALMEIDA, Professor Associado da
Universidade Federal do Espírito Santo, Brasil
Doctor FERNANDO MANUEL DA COSTA BRITO E ABREU, Professor
Associado do Instituto Superior de Ciências do Trabalho e da
Empresa – Instituto Universitário de Lisboa
Doctor JOSÉ LUÍS BRINQUETE BORBINHA, Professor Associado do
Instituto Superior Técnico, da Universidade de Lisboa
Doctor MIGUEL LEITÃO BIGNOLAS MIRA DA SILVA, Professor
Auxiliar do Instituto Superior Técnico, da Universidade de Lisboa
2014

vii
ABSTRACT
Different efforts have been developed focusing on the alignment between
organizations’ concepts. From these initiatives, two have had outstanding relevance:
Enterprise Architecture (EA) and IT Service Management (ITSM). However, these
two approaches are often used complementarily and simultaneously. The integration
of both approaches avoids the need to adopt different frameworks covering
overlapping topics.
In the literature we found few scientific papers regarding this integration. Although
some have tried to integrate these two approaches, we have not identified a proposal
satisfying our integration requirements. The lack of integration proposals increases the
problem’s relevance.
This dissertation proposes the integration between EA and ITSM through the
integration of two of the best known and used frameworks, respectively TOGAF and
ITIL. We analysed the relationship among the concepts from TOGAF and ITIL
identifying a common ontology. We identified similarities between both approaches
and mapped the integration using ArchiMate as a mutual modelling language to
model ITIL, defining an ITIL metamodel and an ArchiMate specialization.
Based on Design Science Research methodology we demonstrated and evaluated our
research proposal using a set of ITIL models and applying the proposal in a field study
inside a public organization.

ix
RESUMO
Diferentes esforços têm sido desenvolvidos visando alinhar as diferentes dimensões
organizacionais. Dessas iniciativas, duas têm tido maior relevo: Enterprise
Architecture (EA) e IT Service Management (ITSM). Contudo, estas abordagens são
frequentemente usadas complementarmente e em simultâneo. A integração destas
abordagens, num referencial comum, evita a necessidade de adoptar diferentes
quadros de referência cobrindo em sobreposição os mesmos tópicos.
Da revisão bibliográfica constatámos que existem poucas referências científicas em
matéria de integração e as que existem não satisfazem os nossos requisitos de
integração. A ausência de propostas de integração aumenta a relevância do problema.
Esta dissertação propõe a integração das abordagens EA e ITSM através da
integração de dois dos quadros de referência de maior relevo, respetivamente,
TOGAF e ITIL. Analisámos o relacionamento entre conceitos TOGAF e ITIL
identificando uma ontologia comum. Identificámos semelhanças entre ambas as
abordagens e mapeámos a integração usando a linguagem ArchiMate como uma
linguagem de modelação mútua para modelar o ITIL, definindo um metamodelo
para o ITIL e especializando a linguagem ArchiMate.
Baseada na metodologia Design Science Research, demonstrámos e avaliámos a nossa
proposta através de um conjunto de modelos ITIL e aplicando a proposta como caso
prático numa organização pública.

xi
ACKNOWLEDGEMENTS
First of all, I am grateful to Professor Miguel Mira da Silva for supporting me through
his encouragement and guidance, and for allowing me to develop this work, opening
the doors to a new world of knowledge.
My thanks also go to Professors José Manuel Tribolet, Pedro Sousa, Pedro Barros,
José Borbinha, Alberto Silva and Artur Ferreira da Silva, who, sometimes without
even realizing it, encouraged me in the most crucial part of my PhD.
My thanks to Professors Fernando Brito e Abreu and João Paulo Almeida for their
constructive criticism, decisive for the outcome of the dissertation's final document.
My grateful thanks for the support of my superiors in the Navy and the Ministry of
Defence who trusted, believed and allowed me to develop my research and apply it in
practice.
I would also like to thank my family, colleagues and friends who always encouraged
me to go forward and to Rita for her valuable help, immense patience and friendship.
Thanks to my in-laws, who always helped me with time management and support.
Thanks to my parents, my best friends but also the best parents anyone could have.
Thanks for always supporting my decisions (not always wise), for your patience, and
for always encouraging and helping me to be a better person.
My special thanks go to my sister, my biggest fan and my unconditional darling.
Thanks sis, for being as you are.
I also want to thank my two “forces of nature”, my dear sons Simão and Afonso, for
still loving your daddy, despite so many absences and hours of play lost.
Finally, a particularly distinctive and meaningful thank you to Sandra, my wife, my
friend, my inspiration, my faithful companion and confidant. Thank you for your
constant patience and support. Without you none of this would have been possible…

xiii
AGRADECIMENTOS
Primeiramente, o meu agradecimento ao Professor Miguel Mira da Silva pelo seu
apoio, encorajamento, orientação e por me ter permitido desenvolver este trabalho,
abrindo-me as portas a um novo mundo do conhecimento.
Os meus agradecimentos também aos Professores José Manuel Tribolet, Pedro Sousa,
Pedro Barros, José Borbinha, Alberto Silva e Artur Ferreira da Silva, os quais, por
vezes sem se aperceberem foram determinantes pelo seu encorajamento na parte mais
crucial do meu percurso académico.
Agradeço também aos Professores Fernando Brito e Abreu e João Paulo Almeida pela
sua critica construtiva determinante para o resultado final do documento de
dissertação.
O meu reconhecido agradecimento pelo apoio dos meus superiores hierárquicos na
Marinha Portuguesa e no Ministério da Defesa, que acreditaram no meu trabalho e
me permitiram desenvolver a sua aplicação.
Aos meus familiares, amigos, camaradas e colegas, que sempre me incentivaram e
apoiaram. Entre eles estão os amigos de sempre e para sempre. Um especial
agradecimento à Rita pela sua valiosa ajuda, imensa paciência e amizade.
Aos meus sogros que sempre me suportaram e ajudaram imensamente a gerir o tão
escasso tempo.
Aos meus pais, os meus melhores amigos mas também os melhores pais que alguém
pode ter. Obrigado por sempre apoiarem as minhas decisões (nem sempre as mais
sábias), pela vossa paciência, compreensão e por sempre me encorajarem, ajudando-
me a ser uma pessoa melhor.
O meu especial agradecimento à minha irmã, a minha maior fã, melhor amiga e
minha querida incondicional. Obrigado mana, por seres como és.
O meu agradecimento às minhas duas “forças da natureza”, meus queridos filhos
Simão e Afonso por continuarem a gostar do pai apesar do sacrifício de inúmeras
horas de brincadeira perdidas.
Finalmente, o mais significativo dos agradecimentos à Sandra, minha mulher, minha
amiga, minha inspiração, minha fiel companheira e confidente. Obrigado pela tua
constante paciência e apoio. Sem ti nada disto teria sido possível...

xv
TABLE OF CONTENTS
ABSTRACT .......................................................................................VII!
RESUMO ......................................................................................... IX!
ACKNOWLEDGEMENTS ....................................................................... XI!
AGRADECIMENTOS .......................................................................... XIII!
TABLE OF CONTENTS .........................................................................XV!
LIST OF FIGURES............................................................................. XIX!
LIST OF TABLES ..............................................................................XXV!
ACRONYMS..................................................................................XXVII!
1! INTRODUCTION .............................................................................1!
1.1! Motivation........................................................................................................3!
1.2! Problem Area ...................................................................................................4!
1.3! Problem............................................................................................................5!
1.3.1! Thesis Statement..........................................................................................6!
1.3.2! Research Objectives ....................................................................................7!
1.3.3! Research Questions .....................................................................................7!
1.4! Research Methodology ....................................................................................8!
1.4.1! Design Science Research Methodology.......................................................9!
1.5! Document Structure.......................................................................................12!
2! LITERATURE REVIEW .................................................................... 15!
2.1! Enterprise Architecture..................................................................................16!
2.1.1! TOGAF .....................................................................................................18!
2.1.2! Critical Analysis.........................................................................................22!
2.1.3! Summary ...................................................................................................28!
2.2! Modelling Languages .....................................................................................28!
2.2.1! Ontology’s Definition and Representation................................................29!
2.2.2! ArchiMate..................................................................................................32!
2.3! Service Oriented Architecture (SOA) ............................................................35!
2.4! IT Service Management ................................................................................38!
2.4.1! ITIL ...........................................................................................................39!
2.4.2! ITIL Modelling Representation ................................................................44!
2.4.3! Critical Analysis.........................................................................................46!

xvi
2.4.4! SOA and ITIL...........................................................................................48!
2.5! Related Work .................................................................................................49!
2.5.1! EA in the ITIL Books ................................................................................50!
2.5.2! SOA, EA and ITIL Relationship ..............................................................51!
2.5.3! TOGAF and ITIL.....................................................................................53!
2.5.4! Extending EA.............................................................................................54!
2.5.5! Alignment between EA and ITIL..............................................................55!
2.5.6! Shared Repository .....................................................................................57!
2.5.7! Tools for EA and ITIL ..............................................................................58!
2.5.8! Synopsis of Related Work..........................................................................58!
2.6! ITIL Metamodels...........................................................................................60!
2.7! Summary........................................................................................................64!
3! COMPARING TOGAF AND ITIL ....................................................... 67!
3.1! Service Strategy..............................................................................................68!
3.2! Service Design................................................................................................70!
3.3! Service Transition ..........................................................................................71!
3.4! Service Operation ..........................................................................................73!
3.5! Continual Service Improvement....................................................................74!
3.6! Summary........................................................................................................74!
4! PROPOSAL .................................................................................. 77!
4.1! Integration Criteria ........................................................................................79!
4.2! Integration Verification..................................................................................81!
4.2.1! EA Terms and Concepts ...........................................................................82!
4.2.2! TOGAF Content Metamodel ...................................................................84!
4.2.3! SOA Principles in Integration Efforts........................................................85!
4.2.4! ITIL Concepts ...........................................................................................86!
4.2.5! Relationship Between Concepts ................................................................87!
4.2.6! Concept Map.............................................................................................90!
4.2.7! Summary ...................................................................................................95!
4.3! Integration Method........................................................................................96!
4.3.1! Modelling ITIL with ArchiMate ...............................................................97!
4.3.2! ITIL Metamodel......................................................................................117!
4.3.3! Integration Viewpoints ............................................................................128!

xvii
4.3.4! Summary of Integration Method.............................................................142!
4.4! Change Management...................................................................................143!
4.4.1! Change in TOGAF and ITIL .................................................................144!
4.4.2! Proposed Change Management ..............................................................145!
4.4.3! Types of Changes ....................................................................................147!
4.4.4! Change Management Viewpoint ............................................................151!
4.4.5! Summary of Change Management .........................................................153!
4.5! Summary......................................................................................................154!
5! DEMONSTRATION....................................................................... 155!
5.1! ITIL Models.................................................................................................155!
5.2! Field Study ...................................................................................................158!
5.2.1! Organization............................................................................................158!
5.2.2! Historical Overview.................................................................................160!
5.2.3! Current EA Project..................................................................................161!
5.2.4! Change Management ..............................................................................173!
5.2.5! Summary .................................................................................................175!
6! EVALUATION ............................................................................. 177!
6.1! Wand and Weber Method ...........................................................................178!
6.2! Moody and Shanks Framework ...................................................................179!
6.3! Action Design Research...............................................................................182!
6.3.1! Interviews.................................................................................................183!
6.3.2! Field Study...............................................................................................185!
6.4! Summary......................................................................................................187!
7! CONCLUSION ............................................................................ 189!
7.1! Answer to Research Questions.....................................................................189!
7.2! Main Contributions......................................................................................191!
7.3! Limitations....................................................................................................192!
7.4! Publications ..................................................................................................193!
7.5! Future Work.................................................................................................195!
REFERENCES.................................................................................. 197!
APPENDIX A –! ARCHITECTURE MODELLING LANGUAGES..........................A-1!
Business Process Modelling...................................................................................A-1!
IDEF......................................................................................................................A-3!

xviii
ARIS......................................................................................................................A-4!
UML......................................................................................................................A-5!
ArchiMate .............................................................................................................A-8!
Language Suitability for Enterprise Architecture .................................................A-9!
APPENDIX B –! EA FRAMEWORKS ........................................................B-1!
Zachman Framework............................................................................................B-1!
ISO/IEC/IEEE 42010.........................................................................................B-3!
The Integrated Architecture Framework..............................................................B-5!
Extended Enterprise Architecture Framework .....................................................B-5!
The Treasury Enterprise Architecture Framework ..............................................B-6!
The CEO Framework...........................................................................................B-7!
APPENDIX C –! EA DEFINITIONS AND CORE CONCEPTS............................ C-1!
APPENDIX D –! ARCHIMATE CONCEPTS AND DEFINITIONS........................ D-1!
APPENDIX E –! SOA ELEMENTS ..........................................................E-1!
APPENDIX F –! ITIL ARTEFACTS AND PROCESSES .................................... F-1!
APPENDIX G –! CONCEPT MAPPING BETWEEN ITIL AND ARCHIMATE ......... G-1!
APPENDIX H –! IMAGES FROM THE FIELD STUDY .................................... H-1!
Previous Project.................................................................................................... H-1!
Current Project..................................................................................................... H-4!

xix
LIST OF FIGURES
Figure 1 – DSR, adapted from (March & Smith, 1995; Peffers et al., 2007)...............10!
Figure 2 – Simplified Ontology Engineering (Ostrowski et al., 2012) .........................11!
Figure 3 – Document Structure...................................................................................13!
Figure 4 – TOGAF Main Parts (Open Group, 2011) .................................................19!
Figure 5 –TOGAF Architecture Content Framework (Open Group, 2011) ..............20!
Figure 6 – TOGAF ADM Development Process (Open Group, 2011) ......................21!
Figure 7 – Views in the TOGAF ADM (Open Group, 2011).....................................22!
Figure 8 - Ontology as filter of knowledge (Calero et al., 2006) ..................................31!
Figure 9 – ArchiMate: Layers and Divisions (Meertens et al., 2012)...........................33!
Figure 10 – Main Concepts of ArchiMate (Open Group, 2012).................................34!
Figure 11 – SOA Paradigm (Haki & Forte, 2010) .......................................................36!
Figure 12 – Layered Services, adapted from (Lankhorst, 2009)..................................37!
Figure 13 – Service Layers (Jung, 2009) ......................................................................37!
Figure 14 – SOA Reference Architecture (Open Group, 2009)..................................38!
Figure 15 – The Three Gears of ITIL (Cabinet Office, 2011b) ..................................39!
Figure 16 – Strategies and Services Relationship (Cabinet Office, 2011b) .................41!
Figure 17 – ITIL Service Lifecycle (Cabinet Office, 2011b) .......................................42!
Figure 18 – ITIL’s Meta-information Related With Services .....................................43!
Figure 19 – IT Service Management Lifecycle............................................................49!
Figure 20 – SOA Service Lifecycle ..............................................................................49!
Figure 21 – Enterprise Architecture in ITIL (Cabinet Office, 2011d) ........................50!
Figure 22 – Enterprise Metamodel (Braun & Winter, 2007).......................................51!
Figure 23 - BITAM-SOA Service Engineering Schematic (Chen, 2008)....................52!
Figure 24 – TOGAF and ITIL, adapted from (Thorn, 2007).....................................54!

xx
Figure 25 - Integrated Service Architecture Framework (Nabiollahi et al., 2010)......55!
Figure 26 – Metamodel of EA/ITIL alignment (Moser & Bayer, 2005).....................56!
Figure 27 –TOGAF and ITIL alignment, adapted from (Sante & Ermers, 2009)......67!
Figure 28 – Service Transition Relationship, adapted from (Lea-Cox, 2013c)...........71!
Figure 29 – Proposal’s Sequence .................................................................................77!
Figure 30 – TOGAF and ITIL Integration.................................................................80!
Figure 31 – Enterprise Architecture Metamodel.........................................................84!
Figure 32 – TOGAF Content Metamodel, adapted from (Open Group, 2011).........85!
Figure 33 – Layered Provision of Services...................................................................86!
Figure 34 – ITIL’s Service Layer Relation..................................................................87!
Figure 35 – Conceptual Map of Integration Between Concepts.................................91!
Figure 36 – ArchiMate’s Business Layer Metamodel (Open Group, 2012) ..............102!
Figure 37 – ITIL Concepts Relationship to ArchiMate - Business Layer.................103!
Figure 38 – ArchiMate’s Application Layer Metamodel (Open Group, 2012).........103!
Figure 39 – ITIL Concepts Relationship to ArchiMate - Application Layer............104!
Figure 40 – ArchiMate’s Technology Layer Metamodel (Open Group, 2012) ........104!
Figure 41 – ITIL Concepts Relationship to ArchiMate - Technology Layer ...........105!
Figure 42 – Motivation Extension Metamodel (Open Group, 2012)........................105!
Figure 43 – ITIL Concepts Relationship to ArchiMate - Motivation Layer.............105!
Figure 44 – Ontological Evaluation...........................................................................107!
Figure 45 – Ontological deficiencies (Fettke & Loos, 2003).......................................108!
Figure 46 – Ontological Completeness, adapted from (Wand & Weber, 1993)........109!
Figure 47 – Ontological Incompleteness, adapted from (Wand & Weber, 1993) .....109!
Figure 48 – Construct Redundancy, adapted from (Wand & Weber, 1993).............110!
Figure 49 – Construct Excess, adapted from (Wand & Weber, 1993).......................112!
Figure 50 – Construct Overload, adapted from (Wand & Weber, 1993)..................112!

xxi
Figure 51 – Proposal ITIL Metamodel......................................................................123!
Figure 52 – ITIL Metamodel Modelled using ArchiMate ........................................125!
Figure 53 – Business Activity Specialization..............................................................127!
Figure 54 – Business Collaboration Specialization....................................................127!
Figure 55 – Business Process Specialization ..............................................................127!
Figure 56 – Device Specialization..............................................................................127!
Figure 57 – Contract Specialization ..........................................................................127!
Figure 58 – Business Role Specialization...................................................................127!
Figure 59 – Stakeholder Specialization......................................................................127!
Figure 60 – Classification of EA Viewpoints (Open Group, 2012)............................129!
Figure 61 – Concepts and Relationships of ITIL – Book Viewpoint ........................130!
Figure 62 – Example of ITIL – Book Viewpoint.......................................................131!
Figure 63 – Concepts and Relationships of ITIL – Process Viewpoint.....................132!
Figure 64 – Example of ITIL Process Viewpoint ......................................................132!
Figure 65 – Concepts and Relationships of ITIL – Process Detail Viewpoint..........133!
Figure 66 – Example of ITIL – Process Detail Viewpoint ........................................134!
Figure 67 – Concepts and Relationships of ITIL – Strategy Viewpoint ...................135!
Figure 68 – Example of ITIL – Strategy Viewpoint..................................................135!
Figure 69 – Concepts and Relationships of ITIL – Service Catalogue Viewpoint ...136!
Figure 70 – Example of ITIL – Service Catalogue Viewpoint..................................137!
Figure 71 – Concepts and Relationships of ITIL – Service Provider Viewpoint......138!
Figure 72 – Example of ITIL – Service Provider Viewpoint ....................................138!
Figure 73 – Concepts and Relationships of ITIL – Service Viewpoint.....................139!
Figure 74 – Example of ITIL – Service Viewpoint ...................................................140!
Figure 75 – Concepts and Relationships of ITIL – Compliance Viewpoint.............141!
Figure 76 – Example of ITIL – Compliance Viewpoint ...........................................142!

xxii
Figure 77 – Concepts and Relationships of Change Management Viewpoint .........152!
Figure 78 – Part of the ITIL Overview Model ..........................................................156!
Figure 79 – Detail of Service Transition Process Model ...........................................157!
Figure 80 – Detail of Incident Management Process Model .....................................157!
Figure 81 – Overview of Defence Domains...............................................................159!
Figure 82 – Secretaria Geral’s Organizational Structure ..........................................159!
Figure 83 – Examples of Models from the Infrastructure Architecture.....................165!
Figure 84 – Service Asset and Configuration Management......................................166!
Figure 85 – Overall CDD’s Service Catalogue..........................................................166!
Figure 86 – Partial Detail of CDD’s Service Catalogue ............................................167!
Figure 87 – Example of a Service Viewpoint ............................................................168!
Figure 88 – Service Provisioning, including Provider Location ................................168!
Figure 89 – Event Management process using ITIL Compliance Viewpoint...........169!
Figure 90 – Overview of the Implemented Solution .................................................171!
Figure 91 – Overview of the Conceptual Solution ....................................................171!
Figure 92 – Change Management Process using the Respective Viewpoint.............173!
Figure 93 – Evaluation Components.........................................................................177!
Figure 94 – Results of Moody and Shanks Evaluation..............................................182!
Figure 95 – Questionnaire Results.............................................................................185!
Figure 96 – BPMN elements......................................................................................A-2!
Figure 97 – Examples of IDEF Models .....................................................................A-3!
Figure 98 – Model of the ARIS architecture.............................................................A-5!
Figure 99 – Examples of UML diagrams...................................................................A-7!
Figure 100 – Zachman Framework ...........................................................................B-2!
Figure 101 - ISO/IEC/IEEE 42010 conceptual framework ....................................B-4!
Figure 102 - Integrated Architecture Framework (IAF) ............................................B-5!

xxiii
Figure 103 - Extended Enterprise Architecture Framework (E2AF).........................B-6!
Figure 104 - Treasury Enterprise Architecture Framework (TEAF).........................B-6!
Figure 105 - CEO Framework Metamodel Profile....................................................B-7!
Figure 106 - ArchiMate’s Business Layer Metamodel (Open Group, 2012)............ D-1!
Figure 107 - Summary of Business Layer Concepts (Open Group, 2012) ............... D-3!
Figure 108 - ArchiMate’s Application Layer Metamodel (Open Group, 2012)....... D-4!
Figure 109 - Summary of Application Layer Components (Open Group, 2012) .... D-5!
Figure 110 - ArchiMate’s Technology Layer Metamodel (Open Group, 2012) ...... D-6!
Figure 111 - Summary of Technology Layer Components (Open Group, 2012).... D-7!
Figure 112 - ArchiMate’s Motivation Extension Metamodel (Open Group, 2012). D-8!
Figure 113 - Summary of Motivation Extension Metamodel (Open Group, 2012). D-9!
Figure 114 – Implementation and Migration Extension (Open Group, 2012) ...... D-10!
Figure 115 – Implementation and Migration Extension (Open Group, 2012) ...... D-11!
Figure 116 - ITIL Processes Across the Service Lifecycle ......................................... F-1!
Figure 117 – Process Using BPMN .......................................................................... H-1!
Figure 118 –BPMN’s Change Management ............................................................ H-1!
Figure 119 – Model of the Communications Area (ATACS)................................... H-2!
Figure 120 – Model of the Communications Area (ATACS)................................... H-2!
Figure 121 – Model of the Administration Systems Technical Area (ATAOS)....... H-3!
Figure 122 – Relationships Between Concepts in the EA ........................................ H-3!
Figure 123 – Sample of Service Catalogue............................................................... H-4!
Figure 124 – Sample of Clusters............................................................................... H-4!
Figure 125 – Sample of Applications........................................................................ H-5!
Figure 126 – Sample of Process ................................................................................ H-5!
Figure 127 – Sample of Actors.................................................................................. H-5!
Figure 128 – Sample of Organization Chart............................................................ H-6!

xxiv
Figure 129 – Sample of Racks .................................................................................. H-6!
Figure 130 – Sample of Servers ................................................................................ H-7!
Figure 131 – Sample of Databases............................................................................ H-7!
Figure 132 – Sample of Networks............................................................................. H-8!

xxv
LIST OF TABLES
Table 1 – Classification of the Different Approaches from Related Work..................59!
Table 2 – Classification of the ITIL Metamodelling Approaches...............................64!
Table 3 – Alignment Between Abstraction Levels.......................................................79!
Table 4 – Criteria to Integrate TOGAF and ITIL......................................................81!
Table 5 – Relation of Concepts (ArchiMate/TOGAF, ITIL and SOA) ....................89!
Table 6 – Cell Colour Code for ArchiMate’s Concept ...............................................98!
Table 7 –Relationship Between ITIL and ArchiMate Concepts ................................98!
Table 8 – ArchiMate’s Metamodel Concepts Distribution .......................................100!
Table 9 – ITIL Concepts Distributed by ArchiMate’s Cells .....................................100!
Table 10 – Redundancy Concepts ............................................................................111!
Table 11 – ArchiMate Ontological Incompleteness..................................................112!
Table 12 – ITIL Overload Concepts.........................................................................113!
Table 13 – ITIL Metamodel Core Concepts ............................................................121!
Table 14 – ITIL Book Viewpoint..............................................................................130!
Table 15 – ITIL Process Viewpoint ..........................................................................131!
Table 16 – ITIL Process Detail Viewpoint................................................................133!
Table 17 – ITIL Strategy Viewpoint.........................................................................134!
Table 18 – ITIL Service Catalogue Viewpoint .........................................................136!
Table 19 – ITIL Service Provider Viewpoint............................................................137!
Table 20 – ITIL Service Viewpoint...........................................................................139!
Table 21 – ITIL Compliance Viewpoint...................................................................141!
Table 22 – Matrix of Change Characterization........................................................150!
Table 23 – Sample of Change Occurrence and Characterization............................151!
Table 24 – Change Management Viewpoint ............................................................152!

xxvi
Table 25 – Change Characterization ........................................................................174!
Table 26 – SOA’s Layers Concepts...........................................................................E-1!
Table 27 – Concept's Mapping Between ITIL and ArchiMate ............................... G-1!

xxvii
ACRONYMS
ADM – Architecture Development Method
BPMN – Business Process Modelling and Notation
CEO – Centro de Engenharia Organizacional
CI – Configuration Item
CIO – Chief Information Officer
CMDB – Configuration Management Database
CMMI4SVC – Capability Maturity Model Integration for Services
CMS – Configuration Management System
COBIT – Control Objectives for Information and related Technology
CRM – Client Relationship Management
DSR – Design Science Research
E2AF – Extended Enterprise Architecture Framework
EA – Enterprise Architecture
E2AF – Extended Enterprise Architecture Framework
EAM – Enterprise Architecture Management
EAP – Enterprise Architecture Planning
EO – Enterprise Ontology
ERP – Enterprise Resource Planning
FEAF – Federal Enterprise Architecture Framework
IAF – Integrated Architecture Framework
IDEF – Integration Definition
IEC – International Electrotechnical Commission
IEEE – Institute of Electrical and Electronic Engineers
IS – Information Systems

xxviii
ISA – Information System Architectures
ISO – International Organization for Standardization
RFC – Request For Change
IT – Information Technologies
ITIL – IT Infrastructure Library
ITSM – IT Service Management
SLA – Service Level Agreement
SOA – Service Oriented Architecture
TEAF – Treasury Enterprise Architecture Framework
TOGAF – The Open Group Architecture Framework
UML – Unified Modelling Language
WFM – Workflow Management

1
1 INTRODUCTION
We live in times of scarce resources. Rationalization is an imperative, even a survival
condition for organizations. Convergence is a critical mote to follow standards with
proved results, especially those based on best practices, minimizing the risk of
experimental efforts and the costs. Moreover, cost reduction is an imperative, and
overlapped projects should be avoided.
Information Technology (IT) plays a fundamental role in organizations. The growing
demand on IT leads to the improvement of key concepts related to Enterprise
Engineering, in particular the alignment between IT and strategic objectives and cost
reduction initiatives (Weill & Ross, 2004; Tiwana & Konsynski, 2010). An integrated
approach to business and IT is indispensable.
In fact, organizations and IT are architecturally so merged that it is hard to define
where one ends and the other begins. The impact of IT in organizations is ever
growing, leading to an also growing demand for IT management. The more
important is the role of IT and the more complex is the IT infrastructure, the harder it
is to manage. As IT infrastructures become more intricate, the cost to operate them
rises. IT departments have to control this constantly growing complexity.
To satisfy the increasing demand of IT, organizations strive for effective and efficient
IT management. Demands, opportunities, and threats are constantly changing.
Therefore, organizations must adapt their structures in order to face emergent
challenges. Both the need for a perfect alignment and the high inter-dependence
between IT and the organizations’ structures increase the pressure to define IT
structures that meet these demands (Zacarias et al., 2010).
Organizations relate different concepts such as people, relationship, structure,
strategies, objectives, processes, and IT. The alignment between different
organizations’ concepts, architectures and views is, more than ever, a requirement.
Moreover, alignment issues are in the top of CIO priorities for the past two decades
(C. Pereira & Sousa, 2005; Chen, 2008; Society for Information Management, 2010).
Enterprise Engineering considers the ongoing developments of social theories that
describe the relations of people, technology and organization’s dimensions. Enterprise
Engineering focus on continuous and mutual influential loops that originate emergent
(some unexpected) behaviors and can only be understood through continuous
appreciation and analysis (Martin, 1995).

2
Thereby, Enterprise Engineering involves the creative application of scientific
principles to develop (including design and implementation) organizations; to operate
the same with full cognizance of their design; and to forecast their behavior
considering the environment (Greefhorst & Proper, 2011). Therefore, Enterprise
Engineering studies an organization systemically as a system interacting with
technology in different ways (Liles & Presley, 1996).
For many years now, different efforts were made related to Enterprise Engineering.
However, results are far from expected, as proved by the disparate myriad of
frameworks and different approaches that have been developed. The gap between the
results obtained and expected are far from satisfactory, leading to an increasing
interest in alignment efforts and related frameworks (Weiss & Anderson, 2004).
Today, there is no fully complete framework to be used as a comprehensive off-the-
shelf Enterprise Engineering framework, ensuring the alignment between IT services
and the organization’s concepts and artifacts. In fact, different frameworks are often
used complementary and, most of the times, simultaneously. Beyond the difficulties
associated with the governance of simultaneous initiatives, parallel projects imply a
duplication of resources and costs. Indeed, even with shared infrastructures we could
hardly avoid a duplication of data repositories, procedures and human resources, to
maintain different efforts aligned.
From these initiatives, two main approaches have had outstanding relevance:
Enterprise Architecture (EA) and IT Service Management (ITSM).
This dissertation will pay closer attention to EA and ITSM through their two best
known and used frameworks, respectively The Open Group Architecture Framework
- TOGAF (Open Group, 2011) and IT Infrastructure Library – ITIL (Cabinet Office,
2011a).
EA is a designation that summarizes the relevant concepts in an organization, how
they are related, and how they fit and work together in different perspectives and with
different views. In fact, EA defines a coherent whole of principles, methods and
models that are used as an integrated approach in the design and realization of the
enterprise’s organizational structure, business processes, information systems and
infrastructure technology. As such, EA provides a common base for understanding
and communicating how to structure systems to meet strategic objectives (Zachman,
1987; Spewak & Hill, 1992; Ross, Weill, & Robertson, 2006; Radhakrishnan, 2008).

3
An EA is a vital instrument for addressing organization-wide integration, allowing the
integration of all organization concepts and granting the alignment between business
and IT (Lankhorst & Drunen, 2007).
Different EA frameworks have been developed. From these, the aforementioned open
standard TOGAF (Open Group, 2011) has gained major relevance (Sessions, 2007;
Sante & Ermers, 2009) and this is why we focus our attention on this framework
instead of any other.
ITSM is a reference model with an integrated approach to effectively and efficiently
manage systems’ complexity in order to deliver IT services. IT services provide a
foremost IT alignment to organizations’ needs with guaranteed quality (Brenner,
2006; Gama, Silva, & Mira da Silva, 2011), and cost and risk reduction (Hochstein,
Zarnekow, & Brenner, 2005).
In this context, a reference model is an abstract framework representing the
relationship of a set of defined concepts recognized in a specific domain enabling
communication among stakeholders of the same interests (OASIS, 2006)
Although there are many frameworks for ITSM, ITIL is the de facto standard for
implementing ITSM (Hochstein et al., 2005). ITIL is a process-focused approach to
the identification, planning, delivery and support of IT services to the business
through a service lifecycle (Bon et al., 2007).
Since ITIL is the most well-known and most widely used framework in ITSM, also
used in daily operation in thousands of organizations worldwide (Hochstein et al.,
2005; Kashanchi & Toland, 2006; Braun & Winter, 2007; Johnson et al., 2007;
Sharifi et al., 2008; Ayat et al., 2009; Correia & Abreu, 2009; Lahtela, Jantti, &
Kaukola, 2010; Peyret, 2011b), we focused our research on this approach.
1.1 MOTIVATION
Even though ITSM and EA are both managerial approaches, they have different
focus: ITSM primarily focus on IT service management (Baioco et al., 2009) while EA
are related to alignment, organization representation, and IT Governance as the basis
for Enterprise Engineering initiatives (Ross et al., 2006).
However, since both frameworks have begun addressing the issue of business/IT
alignment, they are increasingly overlapping. At the same time, the relevance of IT
has changed in organizations. IT is not anymore a mere support for business

4
operations instead, the increase importance of IT lead in define how business people
should undertake their work (Venkatraman, 1994; Bharadwaj, 2000).
Nevertheless, a survey from Forrester (Peyret, 2011b) found that more than 50 percent
of EA groups are not involved in ITIL adoption as recently as 2010. Another higher
percentages is only minimally involved. According to Forrester, the reason is because
only in version 3 of ITIL the role of enterprise architect has been identified although
limited to a single domain: service design. Among the other ITIL process domains,
design and strategy are implemented less frequently. Furthermore, Forrester has also
found that the drivers for ITIL adoption do not include EA (Peyret, 2011b).
We conducted a research overview in this area and it has been surprisingly hard to
find empirical or peer-reviewed work relating the two most prominent approaches in
the Enterprise Engineering field, EA and ITSM. Besides both approaches are
complementary, as far as we know, no integration proposal fully accepted has been
developed.
Academic journals generally focus on the interesting problems of new systems
development and emerging technology, rather than the mundane issues of integration
(Betz, 2003).
Although some have tried to integrate these two approaches by identifying several
benefits from the relationship and integration of ITSM and EA, (Braun & Winter,
2007; Thorn, 2007; Correia & Abreu, 2009; Nabiollahi, Alias, & Sahibuddin, 2010)
we did not identify any satisfactory results, as presented in section Literature Review.
This dissertation covers these two widely used frameworks, and proposes guidelines to
adopt a single initiative that involves the integration between EA (TOGAF) and
ITSM (ITIL). A single initiative integrating EA and ITSM would avoid duplicated
efforts and resources increasing synergies through a common and preferable core.
In this dissertation, we present a proposal to integrate EA and ITSM through the
integration of TOGAF and ITIL frameworks using the best of these two mature and
proved frameworks, giving a scientific contribution to this area with some published
papers.
1.2 PROBLEM AREA
Organizational efficiency and effectiveness results from the alignment between
organizational needs and dimensions (Ostroff & Schmitt, 1993). An organization has
different dimensions, which correspond to different views and viewpoints, namely

5
related with people, organizational perspectives, and technological infrastructure.
That’s why organizations are struggling to adopt practices that allow the best results to
achieve alignment between IT and organization’s dimensions.
EA and ITSM are approaches of Enterprise Engineering focusing on the alignment
between IT and organizations’ dimensions. TOGAF is the most used EA framework
and ITIL is the dominant framework for ITSM.
The problem area is where the phenomena of interest resides (Hevner et al., 2004).
The problem area of this research is Enterprise Engineering, due to the environmental
dimensions with a focus on the alignment of the organization’s dimensions.
This research is thus a contribution to Enterprise Engineering providing a proposal to
integrate EA and ITSM initiatives through the integration of TOGAF and ITIL.
The goal of this research is to acquire knowledge that enables the development and
implementation of a solution to an unsolved and fundamental problem faced by many
organizations.
1.3 PROBLEM
The early IT departments were organized in silos usually operating in a standalone
mode and barely connected to the business. At that time, “quality” was the main focus
and any improvements were based on methods. Standards for Service Management
and Enterprise Architecture initiatives were born in that era (IBM Corporation,
1981).
The trend towards organizing work based on best practice models is a result of a
growing complexity from the relationship between IT and business (Sante & Ermers,
2009). From an internal optimization, the organizations’ next efforts were in customer
satisfaction through service delivery. For the first time, the potential of IT supporting
business was recognized. IT became increasing the value added in service delivery
through a well-defined value-chains of processes, from IT to business and vice-versa.
However, the alignment between business and IT requires an integrated approach to
all concepts and artifacts of the organization (Nadler, Gerstein, & Shaw, 1992).
Different initiatives have been developed in order provide the alignment between
business and IT. From those, as aforementioned, two distinct frameworks have gained
enhancement: TOGAF and ITIL representative of the two most distinct approaches,
respectively, EA and ITSM.

6
On the one hand, studying ITIL involves three major components: Processes,
Technology and People (Curtis, Hefley, & Miller, 2001; Cabinet Office, 2011b). On
the other hand, EA is an organization model that specifies its decomposition into
functional parts, defines those parts, as well as the orchestration among them, to
manage and align IT assets, people, operations and projects to support business
objectives and strategies (Ross et al., 2006; Lankhorst, 2009).
Both TOGAF and ITIL are business oriented, aiming to ensure the consistency in the
development of new products and services addressing business requirements.
However, once TOGAF and ITIL are not connected their respective teams work
separately with little opportunity to share expertise. On the other hand, these two
approaches developed in parallel imply a duplication of efforts and resources, loosing
synergies and increasing costs.
The efforts spent in managing organizational data and resources from these two
different initiatives might become unmanageable, which will influence the
effectiveness and benefits of both implementations.
As both frameworks have a lot in common, they should be integrated to avoid
duplication or overlapping. What is often seen between TOGAF and ITIL is that they
usually describe the same topics from different angles, and in some cases those
descriptions seem to conflict (Cabinet Office, 2011a; Open Group, 2011).
Despite the experts’ recommendation to the integration between TOGAF and ITIL, a
commonly accepted integration proposal has not yet been made (Peyret, 2011b).
Pragmatism should be a guiding principle implementing a framework. Such purpose
implies a cohesive approach, integrating the unique characteristics of each one
framework and leveraging what is common. Architects and service managers should
join efforts to align business and IT with mutual understanding. Specialists from both
domains should work together to achieve a solution that has not yet been identified,
both in the framework description neither in related work.
1.3.1 Thesis Statement
Formally, a problem can be defined as the difference between an expected state and
the current state (Hevner et al., 2004).
Since TOGAF and ITIL are developed with different focus but covering areas of
common interest, we propose to integrate both initiatives into a unique framework,

7
sharing the same team and resources, increasing synergy and solving a problem that
can be defined as:
The absence of integration between Enterprise Architecture and
IT Service Management leads to misalignments and promotes a
waste of resources.
1.3.2 Research Objectives
Through this research, we will provide the guidelines to adopt a single initiative that
involves, more than the merger and alignment, the integration between TOGAF and
ITIL approaches. Thus, this research provides a proposal to adopt a common
guidance of integration between TOGAF and ITIL.
The research objectives should ensure that:
It is possible to integrate Enterprise Architecture and IT Service
Management through TOGAF and ITIL integration; there is a
path that ensures the integration; once achieved, the integration
can be kept updated.
1.3.3 Research Questions
TOGAF’s EA principles are a coherent way to represent an organization as a system,
relating multiple dimensions. The widespread scope of ITIL involves all
organizational dimensions.
Both approaches should be integrated, sharing resources to a common understanding
of organizational representation, along all dimensions and views.
Therefore, this research, “Integrating Enterprise Architecture and IT Service
Management” through TOGAF and ITIL Integration, will be answered through the
following research questions that subdivide the problem:
Q1: Does it make sense to integrate the two approaches?
Q2: How to integrate both approaches, which is the key path to
integration, and how can the integration be defined?
Q3: How to represent the integration between the two approaches and,
especially, their relationship?

8
Q4: Considering the effort and magnitude needed to build and maintain
coherent information, how to keep the integrated information up-to-
date and operationally usable on a daily basis?
The answer to these questions derives more from the process side of the solution than
any other one, namely technological. The solution to the problem we try to address
should encompass a conceptual model, independent of tools or adopted frameworks.
1.4 RESEARCH METHODOLOGY
Considering TOGAF and ITIL together is a problem from Enterprise Engineering
area. The interaction of people, organizations’ dimensions, and technology needs to
be qualitatively assessed to allow the understanding of the developed theory or
problem solving (Hevner et al., 2004).
We should develop and validate a proposal to solve our problem, but we had no initial
validated theory and the existing knowledge was insufficient (Hevner et al., 2004;
Oates, 2006; Baskerville, 2008). Therefore, the methodology chosen was Design
Science Research (DSR) as the methodology that best enables research in Enterprise
Engineering.
We selected this methodology because it is focused on problem solving by creating
and positioning an artifact in a natural setting. DSR seeks to create innovative ideas,
addressing research through the development and evaluation of designed solutions in
order to meet identified needs over interactive steps, enabling us to understand the
nature of the causes and design solutions. DSR is the best research methodology to
create and evaluate a solution to solve the identified problem (Hevner et al., 2004;
Oates, 2006).
This methodology also attempts to create solutions that serve human purposes, rather
than natural science that tries to understand reality. DSR provides a solution but also
studies the artifacts as they adapt to their changing environment and to changes in
their underlying components (March & Smith, 1995).
Our research objectives are therefore qualitative and analytical. The research
produces findings without quantification due to the absence of statistical or numeric
values (Strauss & Corbin, 1990).
Qualitative research is more useful to our problem since the collection of information
is made through perception and business case evaluation (Hines, 2000; Skinner, Tagg,
& Holloway, 2000). Qualitative research was developed through processes with

9
interactive steps as DSR follows a process model with sequence activities (March &
Smith, 1995; Peffers et al., 2007). DSR enables us to understand the nature of causes
and design solutions getting products as outputs (Aken, 2005; Oates, 2006).
Analytical research was conducted by factual analysis and the evaluation of different
perspectives relating IT Service Management (ITIL) and Enterprise Architecture
(TOGAF).
DSR products are of four types that are innovative and valuable (March & Smith,
1995; Hevner et al., 2004): constructs, models, methods, and instantiations.
Constructs are the “language” to specify problems and solutions (e.g., modelling
primitives implemented by metamodels of modelling tools). Models use this language
to represent problems and solutions (e.g., process models implemented as workflows).
Methods describe processes, which provide guidance on how to solve problems (e.g.,
project methods implemented during software package introduction). Instantiations
are problem-specific implementations that aggregate constructs, models, and methods.
In this dissertation we will propose: the EA principles and the concepts from TOGAF
and ITIL as Constructs; a Method to TOGAF and ITIL concepts’ integration; as
Models an ITIL Metamodel and EA viewpoints from ITIL perspective;
Implementations with a real-world case and through the modelling of all ITIL
processes and functions.
1.4.1 Design Science Research Methodology
The DSR methodology aims at the development of solutions to identified problems
and it is applied according to two main processes as illustrated in Figure 1 (March &
Smith, 1995): build and evaluate.
Building is where we construct the solution for a specific purpose. Evaluation is the
process of determining how well the solution performs (March & Smith, 1995).
We follow Peffers (Peffers et al., 2007) in which both build and evaluate processes are
composed by three stages each.
In stage 1 we define our research problem and justify the value of a solution, defining
the objectives for a solution in stage 2. At the end of the build process we will have the
construct with the domain definition and the definition of concepts, principles,
methods, and models. This stage occurs after a literature review and requires a
construction methodology.

10
Figure 1 – DSR, adapted from (March & Smith, 1995; Peffers et al., 2007)
In this context, we understand a methodology as a collection of procedures to help the
development of a new or innovative idea, as is the DSR methodology. So, at the end
of stage 3 we conceptualize a construct describing the problem, specifying the solution
and modelling the relation among concepts (Hevner et al., 2004; Winter, 2008).
As we will see later in this dissertation, the ITIL metamodel is the basis for
representing ITIL integrated with TOGAF. This research shows the relevance of a
specification of ITIL concepts and the importance of their representation and
integration in TOGAF.
In addition to the build process, the DSR methodology has an evaluation process
where the solution is demonstrated and evaluated. This is very similar to Action
Research (Sein et al., 2011). However, Action Research is focused on problem solving
through social and organizational change and DSR is focused on problem solving by
creating and positioning an artifact in a natural setting. On the other hand, Action
Research is clearly focused on discovery-through-action whereas DSR is focused on
discovery-through-design (Iivari & Venable, 2009).
The utility, quality and efficiency of the build process must be rigorously
demonstrated through well-performed evaluation methods. In stage 4, we use our
proposal in a field study within an organizational context to solve a research problem.
In particular, we demonstrate our proposal with a field study in Centro de Dados
from the Defence Ministry. After that, we did the evaluation, in stage 5, using some of
the methods proposed in DSR.
Inference
Theory
HowtoKnowledge
Metrics,AnalysisKnowledge
DisciplinaryKnowledge
Identify
problem &
motivate
The absense of
integration
between EA and
ITSM
Define
objectives of a
solution
A single initiative
merging TOGAF
and ITIL
approaches
Design &
development
Define
principles,
concepts,
methods and
models
Demonstration
Use the proposal
in an
organisational
context to solve
an identified
problem
Evaluation
Practitioners
interviews;
Wand and
Weber
ontological
analysis;
Moody and
Shanks
framework
Communication
This thesis;
Papers
published in
journals and
international
conferences
Integrate TOGAF
and ITIL
approaches
Build Evaluate
Define requisites;
A key path to
integrate
ITIL metamodel;
ArchiMate
specialization
Case study
2 31 4 5 6

11
In the end, the undertaken research must be presented to expert audiences to validate
the proposal. We published papers to present our contribution to the scientific
research community, thus fulfilling stage 6.
Ontology Engineering Process
Although the DSR methodology is widely mentioned, apart from some orientations,
the methodology guidelines are not clear or rarely applied (Hevner et al., 2004). The
methodological guidelines’ lack of specificity or inadequacy indicates its high level of
abstraction (Peffers et al., 2007; Alturki, Gable, & Bandara, 2011).
Therefore, we used an ontology engineering methodology in the build process
(Ostrowski, 2011) to identify and define ITIL’s concepts and respective relationship,
creating ontological constructs. These findings are fundamental to the proposal as we
see further.
The ontology engineering process, as illustrated in Figure 2, is used with the
collaboration of practitioners from the same field apart from the more traditional
literature review (Ostrowski, Helfert, & Xie, 2012). Applying this technique allows us
to systematize a clear methodology, with defined steps and procedures, clarifying
knowledge before developing a solution to the research problem.
Figure 2 – Simplified Ontology Engineering (Ostrowski et al., 2012)
Ontology engineering methodology is very similar to the SABiO (Systematic
Approach for Building Ontologies) method proposed by (Falbo, 2004). SABiO
encompasses the following activities: (i) purpose identification and requirement
specification; (ii) capture existing relevant concepts as well as its relations, properties
and constraints; (iii) explicitly represent the captured conceptualization; (iv) integration
with existing ontologies for reuse and integration purposes; (v) ontology evaluation, to
verify the truthfulness with the ontology purpose and requirements; and finally (vi)
ontology documentation.
Following the ontology engineering process and reflecting on the structure of
concepts, we started by defining the domain and the terms that constitute the first step
defining the terms, their properties and purposes. From the identified terms and
properties we acknowledge their limitations and evaluated possible constraints.
Deﬁne
properties
Enumerate
terms
Create
concepts
Deﬁne
relations

12
After we identified the terms and defined their properties, we created (construct)
concepts and their relationships, providing the ontological vocabulary and symbols
used to define a domain’s problems and solutions (Hevner et al., 2004; Vaishnavi &
Kuechler, 2007).
The DSR methodology and the ontology engineering process promote a solution to
an effective problem through the development of constructs, models, methods, and
instantiations, taking together utility and theory.
Following DSR, in this dissertation we designed and developed a solution to an
identified problem (see Section 1.3 Problem). Our research main goal was the
integration between EA and ITSM through the integration between TOGAF and
ITIL. We defined the constructs from the EA principles and a method to integrate the
TOGAF and ITIL concepts. The achieved models and viewpoints, and the respective
implementation in a field study, validate our proposal.
1.5 DOCUMENT STRUCTURE
Besides the Introduction in this first section, we organized the dissertation following
the DSR methodology, ending with References and Appendixes.
We divided the document in the following sections, illustrated with Figure 3:
• Section 1 presents the motivation, identifies the problem and the research
objectives. It also formulates the research questions, the hypotheses and
expected contributions from this dissertation, concluding with research
methodology and document structure.
• Section 2 identifies the focus area of research and defines the scope. It also
acknowledges the problem, from different perspectives, providing a review of
related work in areas of knowledge interconnected with the dissertation’s
problem. These areas are: Enterprise Architecture focusing on TOGAF; the
adopted modelling language ArchiMate; Service Oriented Architecture; and
IT Service Management with a focus on ITIL. After that, we develop an
overview over the related work integrating TOGAF and ITIL. Afterwards we
analyse some approaches related with the definition of an ITIL metamodel.
We end this section summarizing the theoretical background and the topics to
be addressed.
• Section 3 compares TOGAF and ITIL along the five ITIL’ books and
conclude identifying the differences and the similarities between approaches.

13
Figure 3 – Document Structure
• Section 4 defines the objectives of the solution by presenting the theoretical
foundations and the design of the “Proposal” to answer the research questions
and to provide the expected contributions. This section defines the integration
criteria between TOGAF and ITIL, verifies the integration and defines the
integration method. After that, we present the change management as the
process that ensures the update of the proposal. We conclude this section with
a summary highlighting the principal conclusions.
• Section 5, “Demonstration”, shows how the proposal can solve one or more
instances of the problem. We present the ITIL modelling using the proposal
on a field study with the implementation of the proposal.
Build
3. Proposal
2. Literature Review
2.1 EA
2.2 Modelling
Languages
2.3 SOA
4. Proposal
4.1 Integration
Criteria
4.3 Integration
Model
4.4 Change
Management
Evaluate
5. Demonstration
5.1 ITIL Models 5.2 Field Study
6. Evaluation
6.1 Wand & Weber
6.2 Moody &
Shanks
7. Conclusion
7.2 Main
Contributions
7.5 Future Work
6.3 Action Design
Research
4.2 Integration
Veriﬁcation
7.3 Limitations 7.4 Publications
7.1 Answer to
Research
Questions
1. Introduction
1.1 Motivation
1.2 Problem
Area
1.3 Problem
Thesis
Statement
Research
Objectives
Research
Questions
1. Introduction
1.4 Research
Methodology
1.5 Document
Structure
2.4 ITSM
2.5 Related
Work
2.7 Summary
6.4 Summary
2.6 ITIL
metamodels
4.5 Summary
3. Comparing TOGAF and ITIL
3.1 Service
Strategy
3.3 Service
Transition
3.4 Service
Operation
3.2 Service
Design
3.5 Continual
Service
Improvment
3.6 Continual
Service
Improvement

14
• Section 6 provides the “Evaluation” of our proposal and compares the results
with the research questions. We followed different evaluation methods;
including the Wand and Weber method, the Moody and Shanks framework,
and Action Design Research with interviews in the field study.
• Section 7 “Conclusion” summarizes and evaluates this dissertation, the
research questions as well as proposes themes for further work. Also includes
the “Communication” in which we present the published papers.

15
2 LITERATURE REVIEW
There are some questions that a literature review should answer (Gill & Johnson,
1991):
• What are the fundamental subjects and concepts related to our research?
• What part of our research work has ever been investigated before and what
has not?
• How does our research work relate to that done by others?
• How have others defined and related the key concepts of our research?
• What data sources have been used in developing a concept in the dissertation?
Based on the above issues, this section supports the proposal and assigns the
foundation to answer our research questions. We reviewed the literature covering
areas related to our problem, providing the fundamental background. We also
developed an overview and evaluation of Related Work, identifying gaps and
shortcomings.
Our “Literature Review” analysis identifies the fundamental concepts covered by the
dissertation. It is a long section because our dissertation covers and integrates different
areas of knowledge. We start by review the problem area with “Enterprise
Architecture” (EA) section as the main concept followed by the proposal. EA is
presented as a set of principles, drivers, and concerns to be followed.
In the section “Modelling Languages" we review the architecture modelling languages
with a critical analysis. We identify ArchiMate as the language to modelling an EA
whose requirements best answer to our needs.
The “Service Oriented Architecture (SOA)” section reviews the SOA paradigm
identifying services as an approach that distinct frameworks such as TOGAF and
ITIL follow principles.
In the following subsections of this section we review IT Service Management
focusing on ITIL as the best framework to ITSM (Hochstein et al., 2005; Braun &
Winter, 2007; Correia & Abreu, 2009).
We also analyse the “Related Work” from disparate authors and different approaches,
highlighting the most relevant topics to be considered in our proposal. After that, we
analyse some research works related with ITIL Metamodels
We conclude this section with a summary of the Literature Review.

16
2.1 ENTERPRISE ARCHITECTURE
Enterprise Engineering can be defined as the body of knowledge, principles, and
practices related with the analysis, design, implementation and operation of an
organization as a complex system of processes, systems and people (Liles & Presley,
1996; Dietz et al., 2013).
Enterprise Engineering recognizes Enterprise Architecture (EA) as the core
representational element for the organization’s systems properties in different views
and for many different purposes. We can state that EA has emerged as the basis of
knowledge and representation in the organization itself, as a means of creating a
coherent way of modelling an organization, assuming the methodology that best
enables, efficient and effective, the planning and deployment of systems and IT
aligned with business (Zachman, 1997; Open Group, 2011; Dietz et al., 2013).
In this context, an architecture is a fundamental layer and independent representation
of a system, useful to represent different models as long as overall consistency is
preserved by appropriately modelling the frameworks’ metamodel (Braun & Winter,
2005).
An architecture embodies artifacts, concepts, and components, their relationships with
the environment and stakeholders.
Therefore, an EA is a symbolic representation of an organization in layers and
artifacts that are relevant for an organization, such as structure, activities, processes,
information, people, technology, goals and constraints, containing representations of
individual facts, objects, and relationships that occur within the organization(Ross et
al., 2006; Lankhorst, 2009).
However, even though EA principles make a clear reference to the relationship
between dimensions and artifacts, they do not specify how to define and relate
disparate concepts within an organization (Spewak & Hill, 1992).
Also, EA principles only provide an abstract view of organizations’ concepts omitting
the fundamental foundation for an understandable knowledge (Dietz, 2006).
We define EA as a coherent whole of principles, methods, and models that
are used as key elements in the design and construction of organizations’
structures, business processes, information systems, and technology
infrastructures, in which:

17
• Principles involve the design and performance of different
architectures, the specification of functional parts, their
decomposition, as well as the orchestration among them;
• Models can be defined as the representation of organization’s
architectures, artifacts and the relationship among them;
• Methods provide the steps for assisting in the acceptance, production,
use, and maintenance of an EA.
Through this background, EA involves the design and realization of different
dimensions which correspond to perspectives views (Correia & Abreu, 2009;
Lankhorst, 2009).
A view is a plan describing the deployment of an architecture building block across
the organization, giving a comprehensive view on how they interact, namely between
business, application, information, and infrastructure architecture. A view pictures the
architecture design in a matrix of organization dimensions (Rohloff, 2008).
Therefore,
A view can be described as the way each EA domain or stakeholder looks at
different interests, its structure and elements from a specific perspective. As
such, we will have a disparate variety of views in different architectures.
Different needs and scopes have suggested distinct frameworks and representations for
modelling EA, having in common principles such as: holistic organization’s
representation; relationships mapping between artifacts and concepts along
architectures; independence and connection among layers (Hoogervorst, 2004).
Answering different needs, disparate authors have suggested distinct frameworks, for
instance: Zachman Framework, IAF, E2AF, TOGAF, TEAF, CEO, FEAF, DoDAF,
MODAF, and NAF, to name just a few. In Appendix B – we present an overview of
some of the most relevant EA frameworks.
From all EA frameworks TOGAF has gained major relevance. Nowadays, TOGAF
has a widespread acceptance and it is one of the leading architecture frameworks
worldwide (Cameron & McMillan, 2013). For example, a simple Google search by
TOGAF returns more results (more than three million) than all the others frameworks
together. Therefore, we focus our research in the TOGAF framework (Sante &
Ermers, 2009).

18
2.1.1 TOGAF
TOGAF (The Open Group Architecture Framework) is supported by The Open
Group: a large community of practitioners, vendors and technology-neutral
consortium, focused on a diverse range of open standards and affiliated certification
programmes (Sante & Ermers, 2009; Open Group, 2011).
TOGAF is a framework providing a comprehensive approach to the design, planning,
implementation and governance for EA. This framework provides an agreed baseline
for strategic planning and tactical decision-making.
The first version of TOGAF (1995) was based on the US Department of Defence’s
Technical Architecture Framework for Information Management (TAFIM). The
following six versions of TOGAF addressed technology architecture based on the
adoption of architecture in businesses at the time each was written. In 2002, the
“Enterprise Edition” (version 8) was published, and was followed by a series of
improvements expanding the scope of TOGAF from a purely technology architecture
to an Enterprise Architecture, by including business and information systems
architecture (Sante & Ermers, 2009).
The TOGAF’s evolution follows the changes in the architecture’s role within
organizations. It has increasingly become a process to help organizations to make
decisions about their future and to show them how to get there. By combining inputs
from the whole organization and from different stakeholders, architects can help
organizations to reduce the complexity of today’s IT and organizational landscape
(Jonkers, Proper, & Turner, 2009) (Jonkers et al., 2009).
In fact, an architecture must be seen as an organization-wide process that will be
directed by management, with the support of the enterprise architect. The (enterprise)
architect has therefore changed from a technical individual to someone with
organizational sensitivity (Sante & Ermers, 2009).
TOGAF’s latest version (version 9.1, published on 1 December 2011) expresses the
need for closer alignment with the business, and the desire for simple implementation
and greater usability (Sante & Ermers, 2009).
Alongside a higher level of detail in the description of the architecture, there is
increasing reflection on the use of the architecture and its governance. This is the
same kind of development evolution that occurred in IT Infrastructure Library (ITIL),
where support to the business is now considered vital.

19
The TOGAF specification main parts are illustrated in Figure 4. The core of TOGAF
describes the Architecture Development Method (ADM), a recommended sequence
for the various phases and steps involved in developing an architecture applying
TOGAF.
Figure 4 – TOGAF Main Parts (Open Group, 2011)
The Architecture Content Framework includes a structured metamodel for
architectural artifacts, the use of re-usable architecture building blocks, and an
overview of typical architecture deliverables (Figure 5).
The Enterprise Continuum & Tools discusses appropriate taxonomies and tools to
categorize and store the outputs of architecture activity within an enterprise. The
TOGAF Enterprise Continuum provides a framework and context for the leveraging
of relevant architecture assets in executing the ADM. These assets may include
architecture descriptions, models, and patterns taken from a variety of sources. The
Enterprise Continuum with the architecture assets can be associated with ITIL’s
Configuration Management Database (CMDB) and linked to the configuration
management process (Thorn, 2007).
The TOGAF’s Reference Models include the TOGAF Foundation Architecture and
the Integrated Information Infrastructure Reference Model (III-RM).

20
Figure 5 –TOGAF Architecture Content Framework (Open Group, 2011)
Finally, the Architecture Capability Framework, discusses the organization, processes,
skills, roles, and responsibilities required to establish and operate an architecture
function within an enterprise (Jonkers et al., 2009).
TOGAF ADM
The TOGAF ADM (Figure 6) provides a detailed and well-described iterative phasing
framework for developing architectures to all EA’s domains.
The framework considers an overall EA as composed of a set of closely interrelated
Architectures: Business, Information Systems (comprising Data and Application
Architectures), and Technology (Lankhorst & Drunen, 2007).
TOGAF identifies a number of views, which are modelled in ADM (Lankhorst &
Drunen, 2007). The TOGAF taxonomy of views is compliant with the IEEE 42010
(IEEE Computer Society, 2011).

21
Figure 6 – TOGAF ADM Development Process (Open Group, 2011)
The architecture views, and corresponding viewpoints, as illustrated with Figure 7, fall
into the following categories (Open Group, 2011):
• Business Architecture views, that address the concerns of the stakeholders and
describe the flows of business information between people and business
processes (e.g. people, process, function, business information, usability,
performance).
• Information Systems Architecture views, comprising Data Architecture views
and Applications Architecture views, addressing the concerns of the database
designers, administrators, and software engineers. They focus on how the
system is implemented from the perspective of different types of engineers
(security, software, data, computing components, communications), and how
that affects its properties. Systems and software engineers are typically
concerned with modifiability, re-usability, and availability of other services.
• Technology Architecture views addressing the concerns of the acquirers,
operators, communications engineers, administrators, and managers of the
system.
• Composite views addressing other type of concerns not covered in the
previews views.
www.via-nova-architectura.org March 2007 3
Central to the discussion in this paper is TOGAF’s Architecture Development Method (ADM).
The framework considers an overall Enterprise Architecture as composed of a set of closely in-
terrelated Architectures: Business Architecture, Information Systems Architecture (comprising
Data Architecture and Application Architecture), and Technology (IT) Architecture. ADM is con-
sidered to be the core of TOGAF, and consists of a stepwise cyclic iterative approach for the
development of the overall enterprise architecture (Figure 2).
Figure 2. TOGAF ADM development process [The Open Group, 2006].

22
Figure 7 – Views in the TOGAF ADM (Open Group, 2011)
2.1.2 Critical Analysis
The ADM (Figure 6) is the core method of TOGAF (Open Group, 2011) describing
the lifecycle of organization architecture through a cycle of phases for which we
developed the following critical analysis.
Phase A: Architecture Vision
The Architecture Vision’s objectives are the development of a high-level vision of
capabilities and the delivery of business value. Despite all concerns considered in
architecture vision, in practice, when we develop an enterprise architecture it is not
Figure 3. Views in the TOGAF ADM development process [The Open Group, 2006].
Enterprise Modelling
Modelling languages are an essential instrument for the description and communication of ar-
chitectures, and languages and tools have evolved more or less “hand in hand”. In some cases
methodologies and frameworks have grown around and are supplied together with architecture
support tools, for instance in the case of UML and Rational, EPCs and ARIS [Scheer, 1994],
and Testbed [Eertink et al., 1999]. In other cases, tool vendors have strived to endow their
tools with new functionality in order to support frameworks or other modelling notations such
as UML [Object Management Group, 2003] or the IDEF family [IDEF, 1993], besides their own
proprietary notations (e.g., ARIS, System Architect). Languages and modelling notations are at
the core of all these architecture support packages.
Most languages mentioned provide concepts to model specific domains, e.g., business proc-
esses or software architectures, but rarely do they model the high-level relationships between
these different domains. In current practice, architectural descriptions are made for the differ-
ent domains. Although, to a certain extent, modelling support within each of these domains is
available, well-described concepts to describe the relationships between the domains are al-
most completely missing. Such concepts are essential to tackle the problems of business–IT
alignment and architecture optimization in a systematic way.

23
clear how to put into action key elements such as vision, mission, business strategy and
goals. Even when well documented, TOGAF does not give an answer to that need.
The architecture vision obliges us to clarify a strategy. However, this implies long time
involving business people, which is difficult.
From the organization’s strategy and correspondent goals we have a starting point.
However, we barely have this starting point, leading to a more often bottom-up EA
modelling approach.
Although the creation of business scenarios is expected in this phase (Open Group,
2011), this may lead to misconceptions. Business analysts usually develop business
scenarios with focus on time to market and with no other delivery concerns. For
example, if we developed a product, which creates little profit, it is possible that the
non-functional requirements are inadequately written or poorly implemented, or it is
just an overall bad product. So we need to look at the value added in business
architecture. Therefore, we always need to capture the value and how is delivered,
which is often barely developed at business architecture. The value always depends on
stakeholders’ needs.
Creating business scenarios in TOGAF is very similar to what we did with business
services identification in our proposal, as we will see further on, in Section 4.
Phase B: Business Architecture
Business Architecture is a “prerequisite for architecture work in any other domain” (Open
Group, 2011) documenting and describing the business, supporting functions, and
respective relationships. A knowledge of the Business Architecture is fundamental for
the next steps, namely for integration with strategy, financial management, objectives,
KPIs, and other business’ aspects, specifically the business services. The architecture’s
documentation defines the required business services to be aligned with the respective
enterprise technology – the IT services.
We define IT service based on (Schekkerman, 2004; Vorisek & Jandos, 2010; Gama,
Rosa, & Mira da Silva, 2013),
IT service is a coherent set of activities implemented by processes, delivered
as expected by an IT service provider to an IT service consumer, usually a
business service, which consumes or uses resources (such as applications,
information, or people), supported by the infrastructure technology.

24
Each business service should be supported by the defined IT services and linked to an
SLA between a service provider and the customer.
Despite its intrinsic value, Business Architecture is one of the weakest parts of the
TOGAF framework. In fact, the Business Architecture is not very well described.
Despite the reference to business model principles, goals, and drivers, it is not clear
how to model it. First, TOGAF does not clarify the meaning of Business Architecture.
Moreover, the Business Architecture is neither mentioned in Enterprise Continuum
nor in Architecture Repository. It is merely referred as an EA requirement. Second,
despite the several aspects enunciated in the Business Architecture phase, it still misses
several important aspects such as processes and service delivery.
TOGAF seems too dedicated to identifying business capabilities through the
development of the TOGAF’s Capability Assessment. However, this can be very
difficult in a primary phase due to the lack of process representation and the
inexistence of sufficient information to develop a coherent baseline related to business
capabilities or even to the scope of the architecture.
Without a clear definition of business objectives, financial data, and business processes
we cannot conduct a capability assessment against the current business processes.
Moreover, it is difficult to internally conduct a capability assessment highlighting
weaknesses in the current state.
From another perspective, this phase has a lot in common with the vision statement,
also too descriptive at a high level, without effectively materializing a Business
Architecture, namely in objectives’ definition. For instance, the definitions are missing
and nothing is mentioned about standard best practices. Conversely, the Business
Architecture phase mixes-up the approach to target architecture from top-down to
bottom-up, which does not make sense considering the strategic objectives concern to
the target architecture.
Another less effective area in the Business Architecture phase is the business
modelling. The Activity Models are usually depicted using UML, without sufficient
details and inputs for the following representations. Moreover, it is the only phase
where we consider the business domain and we may lose some of the business
specification representation – the business requirements. UML is good for software
development but too complicated for business users, and to model a real business
architecture expressing organization (Lankhorst, 2009).
In addition, in this phase there is the step “Identify Required Service Granularity Level,
Boundaries, and Contracts” (Open Group, 2011). However, it is very difficult to

25
determine the granularity level at this stage because we can neither identify cross
dependencies, neither needed boundaries. Business people barely understand
architecture granularity. Granularity is something that we may have to decide later,
after the Business Architecture definition, and after we shape the business services,
business processes and the supporting architectures, more from the IT side.
Granularity is easily identifiable from technical services.
We adopted Bohman et al. (Bohmann, Junginger, & Krcmar, 2003) where,
Technical services can be defined, as the decomposition of complex services
into modular units of service simplifying its development and operation.
Nevertheless, this kind of granularity, at this stage, does not mean anything at all for
the business. We believe that the TOGAF’s Business Architecture only makes sense
from a software architecture background.
Finally, despite the importance of having a reference from which we develop the
changing efforts, this phase does not give any definition, or real explanation, of what is
a Business Architecture baseline. However, we should define a Business Architecture
roadmap, thus avoiding starting without an effective planning, integrating the
Business Architecture with the other architectures in a complete business roadmap.
Architecture Integration
Architecture integration relates different architectural domains through an integration
framework. The more different the domains are, the more important is this
framework to enable the architecture’s integration.
On the one hand, one of the TOGAF advantages is the existence of defined
architectural domains (business, data, application, and technology). However, more
and different domains imply different people working and with different detail levels.
TOGAF does not clarify the detail level at vertical scope and usually it is not
consistent. Nevertheless, the detail level should be the same along all the architectures.
On the other hand, despite the compromise in developing different architectures, it is
not clear how to integrate and relate architectures from different domains.
Tools and languages that enable the architecture integration assume a very important
issue. We highlight the importance of a language allowing the integration between
different architectures and the existence of the same detail level.
Finally, TOGAF covers different areas like SOA and security issues, but different
areas are covered in different sections and it is not clear how the relation is established

26
among them. Furthermore, in TOGAF the SOA concept is too focused on technology
and less on the overall concept of service.
Phase H: Change Management
The Change Management phase aims to establish and support the implemented
organization architecture as a dynamic architecture; that is, one having the flexibility
to evolve rapidly in response to changes in the technology and business environment
(Open Group, 2011).
Although TOGAF defines a recommended sequence for the various phases in ADM,
it does not define a scope. The scope should be determined by each organization, as a
framework to pick and choose the parts that we think could help us. Each iteration
will add resources to the organization’s Architecture Repository (Open Group, 2011).
However, the definition of objectives, organizational context and scope, at a
preliminary phase of TOGAF, ignores the continual change of the organization
environment. The identified architectures are too static and we need a framework
reflecting changes in a smooth way. Otherwise, at each change, we have to start again
and redo the same work.
Although Change Management is considered an essential part of the architecture’s
permanent renewal (Open Group, 2011), it is not clear how TOGAF materializes
change management. Since there are many valid approaches to change management,
TOGAF allows the use of other change management processes in place, for instance
ITIL (Open Group, 2011). The TOGAF's change management bridges the gap
analysis between what is projected and achieved. This is quite different from change
management in ITIL, where change management keeps updated the architectural
information databases, as it should be kept in an enterprise architecture.
Management Framework
The TOGAF ADM is a generic method to be used by organizations in a wide variety
of industry types and disparate geographies. It is also designed, if required, for use
with a wide variety of other architecture frameworks (Open Group, 2011). However,
despite TOGAF being presented as inclusive and incentivize the use of other
architecture frameworks, such as ITIL, problems can occur.
TOGAF is a huge framework with many chapters and if we use another framework,
with similar complexity, we may expect some overlapping of covered topics. On the
one hand, this means some problems since people get used to one framework and it is

27
difficult to work in different frameworks. On the other hand, the development of an
adopted framework usually signifies the use of related process and tools, and it is
difficult to integrate different approaches. It is preferable to concentrate in only one
framework, answering all the problems and needs.
Finally, TOGAF exhaustively defines the steps and expected deliverables but it is
merely textually descriptive without a clear definition of processes. As such, TOGAF
is a framework basically of “should have” items: TOGAF describes what should be
done but not how to do it. In addition, TOGAF references are made to the multiple
artifacts and diagrams without mentioning their creation and development practice.
Non-Architectural Inputs
Partnership and contract agreements are presented as non-architectural inputs to EA.
However, partnership and contract agreements are usually done by a commercial part
of the organization and might be difficult to get into the EA. Contract agreements
should be included in EA. For instance, ITIL has processes to lead with suppliers,
partnerships and contract agreements.
Another important limitation is that TOGAF viewpoints are confined to single
architectural layers, making difficult the integration (or lack thereof) between the
different architectural domains (Lankhorst, 2009).
Transition Phase
One of the biggest faults in TOGAF is the inexistence of a planned transition phase.
Once planned and defined a preliminary phase, we need to test and deploy their
deliverables through a planned transition phase. Without a transition phase, EA is
usually very well delivered in paper, but lacking in execution. We should make sure
that we really deploy the planned EA, because if we do not have our tools ready and
tested through a service transition plan then problems can be expected.
TOGAF’s phases C to G
In section 3 (Comparing TOGAF and ITIL) we develop a critical overview of
TOGAF’s other phases, highlighting the principal similarities and differences between
the two approaches.

28
2.1.3 Summary
From TOGAF’s analysis we identified some limitations. It is not clear how some
concepts are applied, namely those related with strategy identification, and especially
with the Business Architecture.
Services identification is a lacking issue. Some efforts are placed in the identification of
business capabilities too early in the phase of architecture development. The
architecture’s granularly identification is also done too prematurely, leading to few
results. Clearly, a transition phase, such as the Service Transition from ITIL, can
mitigate some of these identified gaps.
The creation of a business service architecture could allow the establishment of
business strategy and also its decomposition through architectural layers, connecting
artifacts and elements.
The TOGAF ADM does not clarify how to integrate and relate architectures from
other domains. Another limitation is that TOGAF viewpoints are confined to single
architectural layers, making the integration with different architectural domains
difficult.
On the one hand, integrating different approaches or frameworks in a single initiative
allows the use of the same referential, namely the same modelling language. On the
other hand, a single initiative would avoid the need of following different frameworks
and cover different topics.
The change management process is mainly related to architectural changes, ignoring
the continual change of organization environment. A change management process
should cover any change, from the structural to the one on a daily basis.
TOGAF is too descriptive without consistent references on how to effectively develop
an EA or on how to design viewpoints. A clear description on how to develop and
achieve an architecture and respective processes is important.
2.2 MODELLING LANGUAGES
Some approaches to enterprise modelling lack adequate semantic speciﬁcation,
leading to an inconsistent interpretation and use of knowledge underlying the
terminology of enterprise models (Grüninger, Atefi, & Fox, 2000).

29
The absence of a strong and precise concept definition can lead the terms to become a
source of confusion and lack of understanding. Especially in terms related to IT (such
as application, information system, and business solution) tend to be used
indistinctively in various scenarios (Pedro Sousa, Martins, & Sampaio, 2012).
Therefore, a modelling language should reflect a clear concept definition allowing
their use in disparate contexts. An ontology is the basis for clear concept definition to
a modelling language development, and metamodels are representations of
ontological concepts’ relationships.
In the following sections we develop some considerations related with ontology
definition and representation. After that, we present ArchiMate as the language to
modelling EA.
2.2.1 Ontology’s Definition and Representation
One of the hardest tasks when developing projects within an organization, crossing
different organizational functions and involving disparate people, is getting everyone
to agree about the meaning of different concepts. Without an ontology agreement,
different representations arise for the same reality.
However, the notion of concept is considered to be a subjective notion (Dietz, 2006).
We based our definition of concept from Novak (Novak & Cañas, 2008) in which,
Concept is a perceived regularity (or pattern) in events or artifacts,
representing knowledge.
Etymologically, the word ontology is composed by “onto”, meaning, “what exists”,
and “logos” or “knowledge about”.
As mentioned by Dietz (Dietz, 2006), an ontology allows a formal and explicit
specification of a shared conceptualization, providing a definition of the meaning of
the existing concepts. An ontology is therefore a foundation for understandable
knowledge, aligning individuals and organizations through a definition of concepts
(Gruber, 1995; Dietz, 2006; Gama, Mira da Silva, & Francisco, 2011). An ontology
can be defined as,
Ontology is a formal description of entities through the definition of
properties, relationships, constraints, an behaviours. Thus, an ontology allow
us to create a common understanding and shared knowledge in concept
definition and classification.

30
A rigorous foundation for organizational design, analysis, and operation requires a
formal semantic speciﬁcation through the use of ontologies (Dietz, 2006). Once an
ontology is an explicit conceptualization of what “exists” can be used to explicit a
representation (Gruber, 1995).
An ontology can have an expressed representation by conceptual modeling grammars
(constituted by vocabulary plus meaning) that allow us to construct representations of
the real-world or from a particular domain (Shanks, Tansley, & Weber, 2003; Dietz,
2006).
In addition to the ontological concepts reference, it is preferable to have a graphical
representation of the ontology in which the relationship is recognized among
concepts. An explicit graphical representation as a model of concepts, especially their
relationship, allows for (Zacarias, Pinto, & Tribolet, 2007; Gama, Mira da Silva, et al.,
2011):
• Uncovering undetermined problems;
• Recognizing the links between concepts in different dimensions or views;
• Tracing of the real relationships between concepts.
A graphical representation outlines a conceptual representation clarifying ambiguous
semantics in the model (Shanks et al., 2003). On the one hand, models are effective
artifacts to support communication and to enable organizational understanding. On
the other hand, a graphical depiction of an ontological representation is a model
(Novak, 1990; Anderson, 2006; Novak & Cañas, 2008).
An ontological model is the basis to manage the complexity of a system. This is a full
implementation independent model of the construction and the operation of the
system. Moreover, an ontological model has a modular structure and its elements are
(ontologically) atomic. The representative metamodel is therefore an ontology (Dietz
et al., 2013).
Therefore, metamodels are closely related to ontologies. Both are often used to
describe relations between concepts (Söderström et al., 2001), allowing us understand
the logical structures and generating semantics (Neto & Neto, 2011). However, despite
metamodels are closely related to ontologies, their characteristics and goals are
different (Calero, Ruiz, & Piattini, 2006). Yet, both are often used to describe and
analyse the relations between concepts (Söderström et al., 2001), allowing to
understand the logical structures and generating semantics for best practices
frameworks (Neto & Neto, 2011).

31
One of the most important uses of an ontology is the knowledge’s filtering (Figure 8).
The models and metamodels (models of models) are representations or images of
reality that, by definition, only include a part of this reality. However, this is not a
problem, but an assistance, allowing the filtering capability of undesired
characteristics. In this sense, an ontology is also of assistance in deciding what should
be taken out of the real systems in order to construct the model(s) of a system (Calero
et al., 2006).
Figure 8 - Ontology as filter of knowledge (Calero et al., 2006)
We acknowledge the difference between ontologies and metamodels, once their
characteristics and goals are different. However, a metamodel should be based on an
ontology. Without an ontology, different knowledge representations of the same
domain can be incompatible even when using the same metamodel for their
implementation (Calero et al., 2006). On the other hand, integrating ontologies into
system models have become popular and can be explored to develop alternatives for
modelling ontologies visually (Parreiras et al., 2009).
While an ontology is descriptive and belongs to the domain of the problem, a
metamodel is prescriptive and belongs to the domain of the solution (Gruber, 1995).
Ontologies provide the semantics while metamodels provide a visual interpretation of
the syntax of specific languages that approximate as closely as possible to the ideal
representation of the domain (Baioco et al., 2009).
We will use an ontology to support the identification, description, and relationships of
ITIL concepts. We use this structure as an ontological model on the integration
between TOGAF and ITIL. A metamodel based on this ontology allows a graphical
representation in which the relationship is recognized among concepts.
Ontology Real-world
System
ModelIs based
on
Is a
representation

32
2.2.2 ArchiMate
An architecture language is a prerequisite for linking the different tools used in various
architectural domains, but also needed for the description of integrated architectures
(Lankhorst, 2009).
Most approaches to architecture modelling lack an adequate speciﬁcation of the
terminology semantics of the underlying enterprise models, which leads to inconsistent
interpretations (Grüninger et al., 2000).
Some aspects contribute to a low score in a modelling language, namely:
• Models created in different domains (views) that are not integrated;
• Domain inconsistencies and the relation between views is poorly defined;
• A weak formal basis and a lack on semantic definition;
• A restricted architectural vision, confined to a specific domain such as
business, application or technology subdomains.
Most of the existing modelling languages emphasize some elements, but do not
provide an overall solution to EA. This is because most of them have their origin in
different scopes with defined goals and objectives.
We may say that languages such as UML (Marshall, 2000) are ideal for modelling.
However, they do not scale well to EA (Lankhorst et al., 2004).
From an overview of some EA modelling languages (see Appendix A – Architecture
Modelling Languages), we identified ArchiMate as the language that covers all
domains in the area of organizations (Lankhorst, 2009). Through a graphical
representation, ArchiMate allows modelling business processes, applications, and
technology, helping in the creation of consistent and integrated models.
Besides lightweight and scalable, ArchiMate distinguishes itself from other languages
such as UML by its enterprise modelling scope, achieving what is needed for a
modelling language for EA.
ArchiMate is a high-level modelling language to describe and model architectures,
with methods and best practices (Open Group, 2012). The language is supported by
diverse tools and consulting firms, but is vendor independent and an Open Group
Standard language (Open Group, 2012).
ArchiMate supports the description, analysis and visualization of architectures within
and across business domains in an unambiguous way. As a traditional architectural

33
drawing language, ArchiMate offers a common language for describing the
construction and operation of business processes, organizational structures,
information flows, IT systems, and technical infrastructures. This insight helps
stakeholders to design, assess, and communicate the consequences of decisions and
changes within and between these business domains.
The views are another ArchiMate advantage, addressing a set of related concerns that
are needed by different stakeholders (Open Group, 2012). Views are specified by
means of viewpoints, used to show different stakeholders interests and different
concerns (Lankhorst, 2009).
The current version 2.0 of ArchiMate (Open Group, 2012) has been improved and
expanded, based on many years of practical experience of modelling and analysis of
EA by a worldwide user base. Nowadays, ArchiMate enables the creation of fully
integrated models of the organization’s EA, the motivation for it, and the programs,
projects and migration paths to implementation.
The ArchiMate 2.0 standard consists of three aspects (Figure 9 and Figure 10):
• Active Structure elements – actors, application components and devices that
display actual behaviour or dynamic aspect;
• Behavioural Elements – behavioural concepts, to show who and what
performs the behaviour;
• Passive Structure elements – objects on which behaviour is performed.
Figure 9 – ArchiMate: Layers and Divisions (Meertens et al., 2012)
These three aspects – active structure, behaviour, and passive structure – have been
inspired by natural language, where a sentence has a subject (active structure), a verb
(behaviour), and an object (passive structure). Natural language is the basis of a
Conceitos Gerais
TSMC 2011
25

34
theoretical framework commonly referred as speech-act theory, that provides concepts
for modelling (Eertink et al., 1999). DEMO (Dietz, 2006) is built on this theory.
Each layer caters to one or more architecture domains, providing a natural way to
look at service-oriented models, despite being a component of the integrated model.
The general structure of models within the different layers is similar. The same types
of concepts and relations are used, although their exact nature and granularity differ.
In addition to the three aspects, ArchiMate language defines three main layers (Figure
9 and Figure 10):
• The Business Layer offers products and services to external customers that are
conducted in the organization by business processes, services, and functions
performed by business actors and roles.
• The Application Layer supports the business layer with application services
done by (software) applications.
• The Technology Layer offers infrastructure services (e.g., processing, storage,
and communication services) needed to run applications, performed by
computer and communication hardware and system software.
Figure 10 – Main Concepts of ArchiMate (Open Group, 2012)
The aspects and layers can be organized as a framework, as illustrated in Figure 10.
The Appendix D – - ArchiMate Concepts and Definitions has a detailed description
of all ArchiMate’s relevant concepts.

35
The ArchiMate language integrates the general concepts in different architectural
layers, as illustrated in Figure 10 (Jonkers et al., 2009).
Summarizing, ArchiMate provides a uniform representation for diagrams describing
EA representations. The relations between domains are clearly defined; the models
are integrated with a strong and formal basis; the semantics is well defined, and
overall architecture vision is allowed (Open Group, 2012).
Nowadays, as a modelling standard maintained by the Open Group, the TOGAF
framework is underpinned by ArchiMate notation (Open Group, 2012). ArchiMate
provides specific extensions to TOGAF that address enterprise architecture scenarios
in which a formal modelling notation is required to address specific concerns related
to formal architecture modelling notation (Jonkers et al., 2009).
2.3 SERVICE ORIENTED ARCHITECTURE (SOA)
Service Oriented Architecture (SOA) is a paradigm oriented to provide business
agility in order to respond quickly to changes in business by re-architecting business
processes, creating new ones, or architecting existing services exposed as business
processes (Tsai, Chen, & Fan, 2006).
SOA principles make services modular and loosely coupled, so they can be flexible in
service composition. The loose coupling characteristic of SOA’s agility works as a
basis for achieving architectural alignment. Each service in SOA has different
granularity and may support business processes, singly or with services choreography.
In fact, service composition and orchestration are advantages of SOA (Chen, 2008).
In SOA a service embodies business functions designed for reutilization across
organization levels (Alwadain et al., 2010). A service’s business function is
implemented with a formal, advertised interface.
Despite the promise that SOA is able to promote a shift from writing software to
assemble and integrate services, the meaning of service is different in each referential.
There are many different definitions and misconceptions of SOA that do not
characterize services in the same way (Lankhorst, 2009; Alwadain et al., 2010).
A service in SOA is often focused on IT infrastructure, related to web services and
much more to application’s functions, using the SOA essence paradigm with service
requestors, service providers and service registry, as illustrated in the Figure 11 (Haki
& Forte, 2010).

36
Figure 11 – SOA Paradigm (Haki & Forte, 2010)
Others consider SOA as a reusable component that can be employed in a new
software development paradigm (Tsai et al., 2006). SOA is also often considered an
architectural approach that emphasizes service concept and service consumers as a
base to structure the entire organization (Noran & Bernus, 2008).
However, these service concepts apply equally well to the business as to software
applications. In common, a service provides functionalities as value proposition within
a value chain or within business processes. Whatever the adopted reference
architecture, SOA always has different layers providing services from a lower layer to
an upper one. Therefore, we consider SOA as a set of principles that enable a defined
simple functionality to be provided and consumed as services by other functional unit,
with each layer providing services to the upper level.
In this context,
a service is defined as a unit of functionality that some entity makes available
and has some value, if used, for other entities in layered services.
For the customers or users, the service concept is the result of a separation from the
‘external’ to the ‘internal’ behaviour of a system. The internal behaviour represents
what is required to realize the service and is usually irrelevant to users as they are only
interested in the functionality and quality that will be provided – externally.
A layering approach helps the modeller to formulate and clearly describe the problem
being analysed. At each layer we can distinguish one or more model layers of two
types: service layers and realisation layers. A service layer exposes functionality that
can be “used by” the next higher layer, while a realisation layer models shows how the
consecutive service layer is “realised”, as illustrated in Figure 12 (Lankhorst, 2009).

37
Figure 12 – Layered Services, adapted from (Lankhorst, 2009)
The promise to reutilize services and develop new ones stuck out in the need to an
effective governance of SOA otherwise SOA may become unmanageable. Without a
defined governance there is nothing that really delivers IT and business alignment,
none of its concepts and precepts such as loose coupling, layers of abstraction through
composite services, and reuse. Only with governance may we succeed in SOA
adoption and only with EA are we able to effectively develop governance (Kistasamy,
Merwe, & Harpe; Papazoglou et al., 2007).
EA has an important role to grant the alignment between SOA and business.
Moreover, the SOA principles should be considered to allow the needed flexibility
when deploying services.
We can define a service taxonomy relating different layers (Jung, 2009) as illustrated in
Figure 13, that includes business services, application services and infrastructure
services. A business service represents the business logic; an application service
represents a specific technical functionality that provides reusable technical functions
encapsulating a unit of software and has a published interface; and an infrastructure
service provides non-business functionality based on hardware (Jung, 2009).
Figure 13 – Service Layers (Jung, 2009)
Through layers relationship we define the SOA reference as an enabler to achieve the
value propositions. As shown in Figure 14, the operational systems layer captures
existing infrastructure needed to support SOA. Service layers include physical and
Business service
Application service
Infrastructure
service

38
operational systems components, application assets, infrastructure services, and other
composed or orchestrated services.
Figure 14 – SOA Reference Architecture (Open Group, 2009)
The service component layer contains software components providing
implementation or the fulfilment of services linking the service contract to its
implementation in the first layer. The service layer includes the service description,
runtime contract description and service dependencies. The upper layer is dedicated
to service composition and orchestration to the provision of capabilities to end users
(Alwadain et al., 2010; Open Group, 2012).
2.4 IT SERVICE MANAGEMENT
IT Service Management (ITSM) can be described as the implementation,
management and provisioning of quality IT services that meet the needs of the
business through an appropriate mix of people, processes and IT, focusing on the
relationship with customers (Cabinet Office, 2011b).
In the ITSM area we have different frameworks, such as ITIL - Information
Technology Infrastructure Library (Cabinet Office, 2011b); COBIT - Control
Objectives for Information and related Technology (ISACA, 2011); CMMI4SVC -
Capability Maturity Model Integration for Services (Forrester, Buteau, & Shrum,
2009), and many others covering specific areas (R. Pereira & Mira da Silva, 2012).
Although those ITSM frameworks having a lot in common (Abreu et al., 2010), ITIL
has become the ITSM standard and one of the most widely accepted framework for
managing IT services and infrastructure in the world (Hochstein et al., 2005;
Kashanchi & Toland, 2006; Johnson et al., 2007; Sharifi et al., 2008; Ayat et al.,
2009; Correia & Abreu, 2009; Peyret, 2011b). As example, a simple Google search
A Comparative Analysis of Alternative Approaches 5
3.4 SOA Reference Architecture
An SOA reference architecture, shown in Figure 2, is used as an enabler to achieve
the value propositions of SOA. The objective of an SOA reference architecture is to
offer a guideline for establishing and evaluating the architecture. In addition, it pro-
vides insights for integrating the fundamental components of SOA in SOA layers
(Arsanjani, Zhang, Ellis, Allam & Channabasavaiah, 2007; The Open Group, 2009).
Figure 2. Layers of the SOA Reference Architecture (The Open Group, 2009)
First, the operational systems layer captures existing and new infrastructure needed
to support SOA. It includes the required infrastructure to run SOA, physical and oper-
ational systems components, application assets, infrastructure services, and other
composed or orchestrated services. Second, the service component layer contains
software components providing implementation or realization for services. It links the
service contract to its implementation in the first layer. Third, the service layer, which
contains all SOA services, includes the service description, runtime contract descrip-
tion and service dependencies. Figure 3 is a further elaboration on the service layer. It
represents a middleware view and classification of services on the SOA reference
architecture. Fourth, the business process layer is dedicated to service composition
and orchestration. Finally, the consumer layer is responsible for the provision of the
capabilities, through channels and portals, to end users (Arsanjani et al., 2007; The
Open Group, 2009).

39
over the ITIL's acronym returns more than 23 million results, 20 times more than the
search results from any other framework related with ITSM.
2.4.1 ITIL
Information Technology Infrastructure Library (ITIL) is a collection of process
oriented best practices, documented over the years, related to the effective and
efficient management of IT, and organized according to the service lifecycle
management (Addy, 2007; Cabinet Office, 2011b).
ITIL involves three major components: Processes, Technology and People, as
illustrated in Figure 15 (Curtis et al., 2001; Cabinet Office, 2011b). Achieving a
balance in this triangle is challenging, so these components (individually or not) should
be the origin of the ITIL implementation difficulties (Gama, Silva, et al., 2011).
Processes improve the efficiency and effectiveness of the organization (Ko, 2009) and
are well documented in ITIL’s books. Although they are based on best practices, and
similar for all organizations that implement ITIL, in some organizations processes are
easier to adopt than others. So, the problem should not be in the processes.
Figure 15 – The Three Gears of ITIL (Cabinet Office, 2011b)
On the one hand, technology executes those processes by reducing time, effort and
costs. On the other hand, technology is becoming considered a commodity (Carr,
2003). Acquiring technology that supports IT Service Management is a matter of
budget. So, technology should not be the source of the problem.
People play a fundamental role: they execute the processes and use the technology.
Different people, organizational structures, communication models and cultures
compose organizations. Assuming that processes are feasible and the technology is
available, the conclusion is that the core of the balance lies on people; i.e. the people
component is the key variable for ITIL implementation success.

40
This idea is enhanced in recent versions of ITIL in which people, fulfilling different
roles, are considered a strategic asset because they are simultaneously resources and
capabilities (Cabinet Office, 2011b).
The ITIL benefits and cost effectiveness are well documented (Hochstein et al., 2005).
However, a good number of ITIL adoption projects are not successful (Nicewicz-
Modrzewska & Stolarski, 2008; Ayat et al., 2009). A study concluded that about 30%
of the organizations that were part of the study were disappointed with ITIL
implementation (Cater-Steel & Tan, 2005). Implementing ITIL is not easy (Roepke,
Agarwal, & Ferratt, 2000).
In the year 2000, ITIL V2 was launched to distinguish itself from its predecessor,
mainly by emphasizing the need for close relationships with both the customer and
the supplier. The core focus of ITIL V2 can be defined as being truly process-
oriented, but still coming from a mainly internal IT perspective, focused on IT service
delivery and support (Nabiollahi & Sahibuddin, 2008; Sante & Ermers, 2009).
One of ITIL V2 main concepts is the service catalogue, including service-level
agreements in line with business requirements. But this first instance of the service
catalogue was exclusively focused on IT services (Peyret, 2011b).
The concept of service catalogue remains in the more recent versions of ITIL and it is
still a main concept of service management. The service catalogue provides a central,
detailed and consistent view of IT services, especially for customers, but is likely to
contain more than one view of an IT Service if there are stakeholders with different
requirements.
However, despite the importance of the service catalogue, ITIL lacks guidance on
how to create or develop a service catalogue from scratch (Rosa, Gama, & Mira da
Silva, 2012; Gama et al., 2013).
In 2007, ITIL V3 was introduced presenting the lifecycle principle, whereby the
provisioning of services was considered to be a continuous process, thus covering the
major weakness identified in the previous version, namely being too focused on
technology (Nabiollahi & Sahibuddin, 2008; Nabiollahi et al., 2010).
The ITIL processes in the V3 version were brought together based on the place they
occupy in the lifecycle. One of the big differences from ITIL V2 is that ITIL V3
adopted a greater business-focused perspective (Sante & Ermers, 2009).

41
ITIL V3 also introduced several new elements, particularly the concepts of business
services and service portfolio management, as well as processes for establishing and
maintaining a business service catalogue (service management).
In ITIL, a service is a means of delivering value to customers by facilitating outcomes
that customers want to achieve without the ownership of specific costs and risks
(Cabinet Office, 2011b).
Services are strategic assets from organization’s strategic orientation and management
(Cabinet Office, 2011b). Business strategies define service strategies that define the
services delivery, which in turn influence the business strategy, as illustrated in Figure
16. A business service is defined by the business. If IT provides a service to the
business, but the business does not think of the service in any business context or
semantics, then it is an IT service” (Cabinet Office, 2011b).
Figure 16 – Strategies and Services Relationship (Cabinet Office, 2011b)
ITIL business services are IT services with a business face. When the infrastructure
and operations groups talk about business services, in reality they are also talking
about IT and application services (Peyret, 2011a).
Business services can be decomposed into business activities that aggregate in a
defined sequence and with a given purpose, represented by business processes. A
business process represents all organization activities, distributed across technologies
and applications, that span locations and users (Cabinet Office, 2011b).
ITIL V3 recognizes that a change in an existing service, or the birth of a new one, is
triggered by business needs, and the alignment to the primary business processes have
much more relevance than in the previous versions of ITIL. Therefore, ITIL V3
placed a greater emphasis on defining and implementing a Service Strategy. As this is
a new concept to IT Service Management, best practices in this area were not
abundant, resulting in the adaptation of less mature practices to describe Service
Strategy and with increased difficulty in adoption.
In 2011, a new edition of ITIL was published, providing an update to the V3 version
published in 2007. The OGC is no longer listed as the owner of ITIL, following the
management. It also makes use of its capabilities in
maintaining software applications to bundle technical
support as part of the core service. By adopting a service-
oriented approach supported by service management
capabilities, the vendor has transformed itself into a
service business. This approach has also been adopted by
internal software engineering groups who have changed
from being cost centres to being profit centres.
For example, the market leader in airline reservation
systems originated from a successful internal computer-
based reservation system of a major airline. Such
transformations require strong capabilities in marketing,
finance, and operations.
4.1.2 Understand the customer
Organizations strive to achieve business objectives using
whatever assets they have at hand, subject to various
constraints. Constraints include costs and risks attributable
to complexity, uncertainty and conflicts in the business
environment. The value-creating potential of the business
depends on the performance of business assets. Assets
must perform well at their full potential. The assets may
the variation in the performance of cu
In a trading system, for example, it is
service to feed the trading system wi
data. To minimize trading losses the d
available without interruption during
as many trading desks necessary with
system in place. An investment bank
pay a premium for a news-feed servic
level of assurance than a service used
The difference translates into greater
4.1.3 Understand the oppor
Customers own and operate configur
create value for their own customers.
means of achieving outcomes that en
value creation. For example, for a len
Focus on customer assets
The performance of customer asset
primary concern of service manage
because without customer assets th
defining the value of a service.
Service
strategies
Services for
strategies
Business
strategies
ServicesServices
Strategies
for services
Figure 4.1 Strategies for servic
strategies

42
consolidation of OGC into the Cabinet Office. But the HM Government owns the
ITIL’s 2011 edition.
The current version of ITIL (known simple as ITIL 2011 edition) has few changes
compared to the previous version. In fact, the 2011 edition mainly clarified and
standardized concepts without causing major differences from the previous version.
The ITIL 2011 edition has five stages corresponding to five books as illustrated in
Figure 17.
Figure 17 – ITIL Service Lifecycle (Cabinet Office, 2011b)
The five books can be summarized as follows:
• Service Strategy addresses what to raise and why it provides value to the
business, addressing the areas where to prioritize investments. Among other
things, Service Strategy defines business services and maps them to IT services.
(Cabinet Office, 2011b).
• Service Design defines how to map business requirements into working
services, including new and changed services (Cabinet Office, 2011d). While
Service Strategy addresses what, why and where, the Service Design book
addresses the how to meet the strategic definitions. If Service Design is well
done, the benefits are substantial, such as greater alignment with customer
needs, lower costs, and improved governance.
• Service Transition addresses the deployment of IT services and the related
processes, ensuring that the changes are carried out in a coordinated way

43
meeting the expectations of the business as documented in Service Strategy
and Service Design (Cabinet Office, 2011f).
• Service Operation is the book that most people think represents ITIL,
addressing the specific IT operation issues, including Incident and Problem
Management (Cabinet Office, 2011e).
• Continual Service Improvement is based on the continuous improvement
practice allowing organizations to get better services that meet the needs of the
business, addressing the series of gap analysis between current and desired
states (Cabinet Office, 2011c).
ITIL’s policies and strategies are defined during the Service Strategy phase (Cabinet
Office, 2011b) of the service lifecycle. The strategy definition is also used in the
preliminary phase of EA definition (Open Group, 2011), where, as general rules and
guidelines, the business context, architecture principles, and governance structure are
established.
The concept of service is persistent in the entire ITIL framework. Nowadays, ITIL is
even self-described as a service lifecycle framework. Figure 18 illustrates the relation
between services and ITIL.
Figure 18 – ITIL’s Meta-information Related With Services
In the current version of ITIL, the focus is on the whole service lifecycle management,
allowing us to address the "business alignment aspect", aligning ITIL with business
expectations and strategies, to meet customers’ and users’ demand (Nabiollahi et al.,
2010; Cabinet Office, 2011d; Gama, Mira da Silva, et al., 2011; Gama, Silva, et al.,
2011).

44
The ITIL framework is underpinned by the Configuration Management System
(CMS), which is defined as a set of tools and databases (CMDBs) for collecting,
storing, managing, and presenting data about all Configuration Items (CI) and the
relationships among them (Cabinet Office, 2011d). A CMDB is usually seen as the
repository that supports ITIL services from an operational perspective.
Everything can be recorded as a CI, including hardware, applications, interfaces, etc.,
but also information about incidents, known errors, changes, people, manuals, SLAs,
etc.
Conceptually, a CMS supports ITIL’s management processes, but is also a shared
centre of decisions and the global “as-is” for organizations’ systems. A CMS has a lot
in common with EA principles. However, the ITIL framework makes no reference to
how we can develop these architectures’ definition.
2.4.2 ITIL Modelling Representation
As already mentioned, ITIL is a collection of five books with the best practices related
to the effective and efficient management of IT (Cabinet Office, 2011b).
One of the primary benefits claimed by proponents of ITIL within the IT community
is the provision of a common vocabulary, consisting in a glossary of tightly defined
and widely agreed terms. However, ITIL is a natural language set of concepts
distributed along several documents and IT management processes and methods
(Hochstein et al., 2005). The modelling object is IT service management, and the
language of description is a natural language (Hochstein et al., 2005), while its
processes are usually depicted as defined sequences of activities by flow charts.
Once ITIL processes, concepts, and relationships are specified in natural language,
without a formal and commonly accepted semantics, modelling graphical
representation is complex (Valiente, Garcia-Barriocanal, & Sicilia, 2012). We
identified some weaknesses modelling ITIL:
• Unclear concepts definition, leading to different interpretations;
• Poor definition of information models corresponding to process descriptions;
• Lack in formal notation and representation, leading to loosely depicted
graphical diagrams;
• Focus on logical description of processes directing what should be done, but
not how to do it;

45
• Different approaches and methodologies to the same problems, making
difficult exchange and knowledge sharing;
• Lack of holistic visibility and traceability from the theory to practice;
• Different approaches to implementation and tools development;
• Models developed from a language description and not from a universal
referential.
Some efforts have been done to illustrate ITIL concepts, relationships, and respective
concepts and artifacts through visual representations (Hochstein et al., 2005;
Strahonja, 2009; Valiente et al., 2012). However, it is mainly in process modelling, by
flow charts or using Business Process Model and Notation (BPMN) (Object
Management Group, 2011), with a formal representation with known symbolic and
semantic models.
We acknowledge the high value of BPMN as a well defined and formal syntax, and a
semantic description specified by the OMG (Object Management Group, 2011).
However, these BPMN representations of ITIL are usually depicted just as a process
architecture to process modelling, not covering business, application, or infrastructure
issues. The main purpose of BPMN is to provide a uniform notation in terms of
activities and their relationships (Lankhorst, 2009).
Besides ITIL’s official books diagrams and BPMN representations, we found other
notations most of them ad-hoc diagrams. These were mainly in-house sketches,
diagrams, and flowcharts expressing the ITIL views of their authors. Because they are
so many and so distinct, its description would be lengthy and hardly noteworthy.
Additionally, we have also come across with some commercial solutions. Thus, we
have chosen three of the most popular ones to include here as an example on how
ITIL is usually represented (IT Process Maps, ITIL Process Map, Microsoft,
Microsoft Visio, IDS Scheer’s ARIS, iGrafx Flowcharter/Process, foxIT, foxPRISM
and Casewise are all registered trademarks).
ITIL Process Map (http://en.it-processmaps.com), from IT Process Maps, is
announced as ”a complete reference process model, designed to serve as a guideline and starting point
for your ITIL and ISO 20000 initiatives”. The product is a set of process models mapped
in the Business Process Model and Notation (BPMN) (Object Management Group,
2011), with processes, artifacts and events. The diagrams have drill-down capabilities
and it also has a responsibility assignment matrix (RACI) to illustrate the participation
of the ITIL roles in the various ITIL processes. It is available for several platforms, as
Microsoft Visio, IDS Scheer’s ARIS, and iGrafx Flowcharter/Process.

46
foxPRISM (http://www.foxit.net/pages/toolkits/foxPRISM.shtml) from foxIT is a
tool that consists of ”a fully interactive web based process knowledge base that assists in the design
and management of Service Management processes and the implementation of Service Management
tools (...) provides a customizable framework onto which organizations can map and build their own
process models”. This web tool uses flowcharts in swimlane format and text to describe
ITIL processes. The elements are processes, activities, roles and events. It also uses a
RACI matrix to map roles to processes.
Casewise Online Visual Process Model for ITIL (http://www.casewise.com/itil) is a
web tool described as ”the world’s first diagram-only view of all guidance for each of the five new
ITIL v3 books providing organizations with the insight to simplify the alignment of business processes
ensuring all ITIL standards are met by using simple frameworks and mapping tools”. It has all the
ITIL processes modelled in BPMN, with processes, activities and events. Also has
drill-down capabilities and in each process it is possible to check each process
according to Critical Success Factors (CSFs), Key Performance Indicators (KPIs), Best
Practice Tips and Hints, Risks and Controls.
It is noticeable from these representations that ITIL is often depicted as just a process
architecture, hence the use of flowcharts or BPMN.
We acknowledge the added value of these tools, models and representations. We are
not claiming they are incorrect, but pointing out they lack completeness, because they
limit themselves to the representation of business and informational concepts, not
considering other domains.
We conclude that these representations describing ITIL lacks on a common semantic
and a clear and formal notation. However, the main purpose of an organization's
overall representation is to provide a uniform notation in terms of activities and their
relationships (Lankhorst, 2009).
2.4.3 Critical Analysis
ITIL offers a set of best practices for IT service management. However, there are
accusations that following only ITIL, due to its acceptance by IT professionals and
managers, has led to skip pragmatic solutions for specific business needs (Addy, 2007).
ITIL’s modelling representation is one of the main problems. ITIL processes,
concepts, and relationships are specified in natural language, without formal and
commonly accepted semantics. Despite being based on best practices with a well-

47
defined set of processes, modelling a graphical representation is complex and worse
when there is no defined modelling language.
The definition of service management as “a set of specialized organizational capabilities for
providing value to customers in the form of services” (Cabinet Office, 2011d) establishes a clear
link between the customer and organizational objectives, regarding the type and
quality of services to be delivered and to organize IT to satisfy these needs. This
characteristic is close to EA principles.
This service definition is useful when discussing service-level agreements, but it does
not address how the business performs a capability or how it might change it. In
addition, ITIL business services are only based on and managed by IT, and the
enterprise may use internal services other than those supported by IT or externally
sourced services.
The ITIL framework prompts to look at IT services as part of a larger, more
important initiative that supports the needs of the organization, avoiding the
technological silos.
It should be noted that ITIL only offers guidance, it could not be implemented: it is a
descriptive framework, not a prescriptive one with mandatory guidelines. Moreover,
ITIL does not prescribe the type of organization, but instead describes the
relationships among the activities in the processes that are relevant to any
organization.
Another criticism of ITIL is that, while some topics are covered extensively and are of
high value, other topics do not receive enough emphasis, namely the holistic approach
to IT management.
Management of the organization’s IT assets is central to ITIL. This is where a well-
developed EA can be very valuable, providing IT managers with a clear
understanding of the IT applications and infrastructure, the related business processes,
and the various dependences between these domains (Lankhorst, 2009).
We can use ITIL in EA to design the service management of an organization.
However, ITIL neither provides a complete coverage for all layers within an EA nor
does ITIL specifies implementation details (Wout et al., 2010).
The main structural differences between ITIL and architectural frameworks for EA is
that ITIL does not change the organization’s own business processes while it runs IT
operations and delivers IT services. These differences are still a heritage from both

48
frameworks’ earlier versions, when ITIL was just about service delivery, and support,
and architectural frameworks just about EA.
However, it is clear that the development of ITIL has been strongly influenced by the
development of organizations in general, leading to a much closer relation to EA
principles. Furthermore, its scope has grown to areas even outside IT to enable IT
services to keep in line with constantly changing business needs.
The earliest versions of ITIL hardly contained any references to architecture as a
concept, method or framework (Sante & Ermers, 2009). For example, in the book IT
Infrastructure Management (ITIL V2) the word architecture is frequently used, but
only in the sense of a design, and not in the sense that is used in TOGAF. Only ITIL
V3 contains numerous references to architecture concepts, albeit not in a very
unequivocal way, usually found through the role of EA but limited to the service
design domain.
ITIL encapsulates a composition of architectures, namely business, processes,
information, application, and infrastructure. However, ITIL has no structured
analysis methodology underpinning and the drivers for ITIL adoption do not include
EA.
Sometimes ITIL employs an operational integration from bottom-up, in order to
model IT architecture in the business processes. Other times, what began as a top-
down approach from business, is frequently conducted into a disjointed and inflexible
IT solution, disconnected from the strategy of the organization.
2.4.4 SOA and ITIL
Service orientation promotes interoperability by minimizing the requirements for
shared understanding: a service description, and a protocol of collaboration and
negotiation, are the only requirements for shared understanding between a service
provider and a service user (Lankhorst, 2009).
The concept of service has a central role in IT service management. ITIL, based on
the service lifecycle, aims improving the quality of service delivery and the
synchronization of these services with the needs of their users (Bon et al., 2007).
There are a lot of similarities between the ITIL Service Management lifecycle (Figure
19) and the SOA service lifecycle (Figure 20).

49
Figure 19 – IT Service Management
Lifecycle
Figure 20 – SOA Service Lifecycle
Therefore, we should be able to apply the SOA paradigm to the ITIL service
management lifecycle. However, the service concept should be used and understood
in the different organizational domains. Using the service concept, the business and
IT have an understandable “language”, which facilitates the communication.
By focusing on services, many opportunities for reuse of functionality will arise,
resulting in a more efficient use of existing resources. Existing services can be
recombined, yielding new products and services.
2.5 RELATED WORK
Research literature from related work can be reviewed for different purposes: to
provide a theoretical background for research; to learn the breadth of the research
field; or to answer practical questions by finding out what is said in existing research
literature (Okoli & Schabram, 2010).
In this section we present the published work specifically about the relation between
EA and ITIL, identifying the most relevant issues to be considered for further
development.
It should be noticed that despite the interest and research in both areas, ITIL and EA
have rarely been studied together. In fact, few relevant researches about the
relationship and interactions between these two approaches have been developed.
Furthermore, most of the previous work has concentrated on ITIL V2, only covering
Service Delivery and Service Support (Nabiollahi et al., 2010). Consequently, this
subject remains without significant development, which increases the interest and
relevance of our research work.
service!
strategy!!
service!
design!
service!
transition!
service!
operation!
service!strategy!!
service!
architecture!and!
design!
service!
deployment!
run!time!

50
2.5.1 EA in the ITIL Books
ITIL promotes the connection with EA only during “Service Design” recognizing that
architectural components should cover technology areas (Cabinet Office, 2011d). EA
can ensure several benefits, namely communication improvement, architecture
documentation, integration between strategy and services, increase agility, and
strategic views for the IT infrastructure and the services delivered, satisfying current
and future needs.
However, ITIL does not explain how to deploy EA benefits. EA is integrated within
Business/Organization Architecture without clarifying who leads the creation of
Service Architecture. On the other hand, ITIL deployment does not consider the
architectural conception, and the distinction between EA and IT architecture is not
clear.
The EA reference, as illustrated in Figure 21 (Cabinet Office, 2011d), is more related
to IT architecture, whereas Service Architecture is, in fact, IT (that we will define as
technical services) was considered the translation of applications, infrastructure and
support activities, in a way very similar as in SOA definition.
Figure 21 – Enterprise Architecture in ITIL (Cabinet Office, 2011d)
On the other hand, neither the processes architecture layer exists in ITIL nor the
principle related to processes, besides the core of processes management from ITIL.
Even considering service design as an inherent part of EA to support business
processes, applicable after the business architecture, there is no explanation in ITIL
books on how to depict business processes from business architecture. Neither how

51
business processes support the business strategy nor how services are linked to
applications and information architecture.
Despite service strategy’s high level of abstraction, EA should play a significant part in
positioning IT’s strategy in the context of business strategy in an operational way.
However, the ITIL books lack on the role of EA in ITIL.
2.5.2 SOA, EA and ITIL Relationship
Braun and Winter (Braun & Winter, 2007) proposed an EA expansion to integrate
ITIL (V2 at the moment) and SOA, considering EA a pivotal concept with ITIL
regarded for IT operations.
In this paper, EA is the model to integrate the relationships among the business,
processes, application, software and technology architectures. EA provides an
overview of the IT architecture to support IT services, whereas ITIL is assigned to the
IT architecture as an essential part of management processes to services delivery.
The effective service delivery and the key elements identified in ITIL benefit from the
defined relationship between dimensions, documented in an EA framework, enabling
cross-layered analyses (Braun & Winter, 2007).
The paper proposes an enterprise metamodel (Figure 22) used to define IT services,
mapping each CMDB’s CI category into a generic framework.
Figure 22 – Enterprise Metamodel (Braun & Winter, 2007)
However, this proposal does not address the mapping between all elements, namely
the mapping between artifacts within layers, which we consider a fundamental EA
principle.
ment has to comprise the
p to IT services.
ental SOA concepts and
ture
a vision of a world in
and consistently repre-
ices [23]. Following this
of an enterprise and their
s of services. Doing that
deliver loosely coupled
ced, insourced or bundled
23].
service orientation para-
nd implementing it in an
lexibility (adaptability to
ut also agility (adaptabil-
ges) [24].
derstanding of the SOA
oftware engineering. The
m of distributed systems
mponents which can be
ns can be published and
e used more flexibly, and
Figure 3. Enterprise service metamodel
Service specification comprises all information about the service
that service users need - without having to know any implementa-
tion details of such service [25]. All available services and their
specifications are stored in a service registry. The service specifi-
cation is implemented by means of a service interface [28].
Enterprise services can be part of IT services, if they are provided
together with other service components, like infrastructure ele-
ments or additional services, like training or customizing services
(see also Fehler! Verweisquelle konnte nicht gefunden wer-
den.). Loosely coupled, reusable and composable enterprise ser-

52
Aligned with IT services, the SOA concept is also integrated into EA at the
application architecture level. ITIL and SOA were integrated into EA as a framework
to deliver IT services, introducing a new view in the metamodel. Braun conducted his
research focusing ITIL only on the IT services delivered (Braun & Winter, 2007).
It is also not clear how was mapped the activities' sequence (the process concept) to
deliver the business and technical services or what the difference between them.
While an essential part in IT services delivery, ITIL is only assigned to the
infrastructure, application and software layers. As such, ITIL is integrated into a
dominant model for enterprise governance (EA) only as a framework delivering IT
services. IT services were considered a new view in the metamodel, presenting by this
way IT service management in the EA framework.
Chen (Chen, 2008) proposes the BITAM-SOA Service Engineering Schematic
illustrated in Figure 23. This research aims to answer business-IT alignment needs
developing a model through top-down or bottom-up approaches. This business-IT
alignment via architecture is integrated with SOA to develop a service-based system.
Figure 23 - BITAM-SOA Service Engineering Schematic (Chen, 2008)
EA is considered the principal structural mechanism for enterprise design from the IT
perspective, whereas ITIL is mainly considered to support IT namely through Service
Support and Service Delivery activities.

53
The alignment approach between SOA, EA and ITIL has been therefore proposed by
Chen (Chen, 2008) and Braun (Braun & Winter, 2007). However, both proposals are
based on ITIL V2 and suggest a relationship and not their real integration.
Instead, in this dissertation we propose to integrate ITIL and EA in a single body
restricting resources and efforts.
2.5.3 TOGAF and ITIL
Thorn (Thorn, 2007) approaches the relation between TOGAF and ITIL,
considering that both approaches are architectural frameworks addressing business
and IT integration. However, were recognized different concerns:
• ITIL is considered an operation model for IT, focusing on IT services delivery
to guarantee the consistency of services through the use of standard processes,
such as Change Management;
• TOGAF is regarded as a methodology focusing on EA development to
guarantee consistency for new products or services addressing business
requirements;
• TOGAF is based on an enterprise architecture repository, whereas ITIL is
based on a CMDB (Figure 24).
The CMDB is the repository that supports ITIL services from an operational
perspective. An EA repository is used to store the reference patterns and the
architecture building blocks used during the architecture development process.
As a CMDB does not really have a predefined metamodel, the latest should be aligned
with the EA repository’s existing models. Another option is using the CMDB to store
the architectural assets, which therefore considered as a virtual repository for EA. This
extended metamodel of a CMDB could integrate the missing information related to
EA.
The scope of the architecture can be linked to the scope of the configuration
management process that is the range of responsibility covered by the process. This
should guarantee consistency between the two domains.
In short, Thorn argues that both frameworks can be used together by mapping the
two approaches (Figure 24): TOGAF covering the development of EA involving the
product’s conception lifecycle, and ITIL ensuring the delivery and management of IT
services at the operational level (Thorn, 2007).

54
Figure 24 – TOGAF and ITIL, adapted from (Thorn, 2007)
Thorn recognized that is still needed different teams as well as different tools to
support both TOGAF and ITIL. The two frameworks are treated complementary,
since TOGAF needs an EA repository, while ITIL requires a CMDB, and alignment
between them depends on the alignment of the two metamodels. However, despite the
absence of an ITIL metamodel the authors did not proposed one.
2.5.4 Extending EA
A more recent research proposes a service based framework for EA meeting the
ITSM requirements from ITIL V3 (Nabiollahi et al., 2010). Nabiollahi et al. suggested
that EA should be extended to involve the service architecture layer from ITIL
Service Design (Cabinet Office, 2011d).
This research is one of the few studies focused on a more recent version of ITIL (ITIL
V3) proposing to cover the overall IT service management. The proposal includes an
Integrated Service Architecture Framework (ISAF) architecture model for IT services
Services
Consistence
Enterprise
Continuum
Resource
Base
Figure 1. TOGAF [The Open Group, 2006].
TOGAF Architecture Development Method
Central to the discussion in this paper is TOGAF’s Architecture Development Method (ADM).
The framework considers an overall Enterprise Architecture as composed of a set of closely in-
terrelated Architectures: Business Architecture, Information Systems Architecture (comprising
Data Architecture and Application Architecture), and Technology (IT) Architecture. ADM is con-
sidered to be the core of TOGAF, and consists of a stepwise cyclic iterative approach for the
development of the overall enterprise architecture (Figure 2).
Figure 2. TOGAF ADM development process [The Open Group, 2006].
Requirements
Requirements
Solution
Solution
Service
Service
Enterprise Architecture Repository
ARCHITECTURE DEVELOPMENT AND SOLUTIONS
TOGAF
Enterprise Architecture Consistence
Problem
Incident
Conﬁguration
Capacity
Continuity
Availability
Change
Release
SLM
Finance
CMDB
SERVICE DELIVERY
ITIL
Models

55
presenting ITIL as a service layer for EA (Nabiollahi et al., 2010). Figure 25 illustrate
the Integrated Service Architecture Framework (ISAF).
Figure 25 - Integrated Service Architecture Framework (Nabiollahi et al., 2010)
Therefore, the paper strives to propose an integrated framework between ITIL and
EA. However, in practice, the target framework aims to design a service architecture
model for the ITIL V3 framework. The paper refers that EA should be extended to
involve the service architecture layer, but does not explain how to define this service
architecture layer and on how the relationships between architectures are defined and
established.
2.5.5 Alignment between EA and ITIL
Other interesting work focuses on how IT architecture can be aligned with ITIL. In
his research Moser (Moser & Bayer, 2005) argues that ITIL describes the
requirements in a service management and business. However, is well recognized that
ITIL does not recommend a detailed metamodel for the technical baselines, and
further standards have to be taken into account. To overcome this gap, was proposed
and used the concept of EA (Moser & Bayer, 2005).
IT services were considered the core elements in ITIL. IT services and the underlying
IT architectures were the main concepts in the alignment effort. EA frameworks
structure organizations, according to a specific set of categories, and they have also
been considered (Moser & Bayer, 2005).

56
Service catalogue appears as the ideal connection point to integrate IT architecture
management with service management. It was recommended to restructure the
service catalogue on the business architecture level according to the business
processes. For successful integration of the expanded service catalogue concept,
architecture management must be aligned with the ITIL processes (Moser & Bayer,
2005).
According to Moser, the concept of the service catalogue is used as a starting point.
Hence, a metamodel of a service catalogue, which meets the requirements of ITIL,
was derived from the ITIL guidelines (Moser & Bayer, 2005).
A metamodel of a service catalogue in conformity with ITIL was developed and the
IT services were structured across cascading service domains of the EA. Despite the
different integration model at each architecture layer, the types of service components
are assigned to architecture layers as illustrated with Figure 26.
Figure 26 – Metamodel of EA/ITIL alignment (Moser & Bayer, 2005)
The aim of the metamodel was to expand ITIL’s concept of the service catalogue to
support architecture management. For this purpose the service catalogue was
understood as the support of the IT organisation to design and assemble IT services.
The metamodel of the service catalogue was mapped to a modelling method and for
each architecture level special model types according to the metamodel were realised.
Even so, we noticed some shortcomings in the proposed ITIL metamodel. One of the
main limitations is the metamodel's focus be only on service catalogue.
The integration of all related concepts was elaborated by the use of an Enterprise
Model Integration based on metamodelling concepts and notation of a modelling
language. However, Moser did not materialize this interesting approach and was not
defined a modelling language. On the other hand the modelling has not a defined
method and we cannot ensure the modelling correctness.

57
FEA was chosen as the EA framework since, according to Moser, FEA is a business-
focused approach that can be applied outside IT. FEA consists of related reference
models including a service reference model and a technical reference model that could
be used.
Emphasis was given in the requirement to use a common and standardised
vocabulary, considered by the continuous usage of ITIL vocabulary. However, we did
not identify any efforts related with the ITIL’s concepts identification and validation.
On the other hand, only ITIL v2 has been addressed.
Summarizing, integrating the IT domains of “IT Architecture” and “IT Service
Management” by means of introducing a service catalogue has shown to be valuable
and with high potential despite the final result is somehow far from expected.
2.5.6 Shared Repository
Another research concerned with a more generic and technology-independent view
on IT services was developed by Correia that proposes the integration of EA with an
ITIL-based CMDB (Correia & Abreu, 2009). In this research, ITIL supports services
from an operational perspective through a CMDB, while an EA repository is used to
store the architectures. Nevertheless, both share a common data-model and the same
ontology.
This paper suggests a common ontology, a metamodel and the sharing of IT services,
namely the formal representation of framework concepts and their relationships.
In this approach, EA is the leading and the CMDB the current state: CMDB keeps
the records of CIs; the EA repository keeps the records of business processes,
relationship between processes and IS artifacts that conduct them, the dependencies
among the applications and their communications through exposed interfaces, and
the technological infrastructure.
Modelled artifacts are created and kept in the EA repository along their relationships
with the rest of the EA. Linking the two repositories, the artifacts are recorded in both
areas (EA and CMDB) keeping their details and information in the CMDB to support
ITIL needs such as incident management.
In short, this approach uses EA for strategic planning and the ITIL CMDB to support
and maintain the current systems in an operational way.

58
2.5.7 Tools for EA and ITIL
Orbus Software (http://www.orbussoftware.com) regularly presents some interesting
white papers related to EA (Lea-Cox, 2013a, 2013b, 2013d, 2013c). Despite some
commercial efforts highlighting the advantage of their products, the white papers are
quite interesting as regards the relation between EA and ITIL.
Orbus stresses the problems verified in many organizations that develop Service
Management initiatives and parallel EA projects. The focus is on the ITIL description
emphasizing how ITIL can be related to EA, namely with a TOGAF adoption.
However, no single framework is proposed, instead it is presented how Orbus
solutions and products can help link the two different approaches.
Regarding tools suppliers that support ITIL and EA, despite the on-going diversity
and orthogonally of tools to support EA and ITIL, to our knowledge there is no tool
to rule them all. With different scopes, all ITIL and EA tools have disparate purposes.
EA tools (BizzDesign, System Architect, Power Designer, just to name a few) focus on
representing EA, expressing concepts’ relationships across architectural layers.
Basically these tools are appropriate to represent the organization “as-is” and forecast
the “to-be” architectures.
As for ITIL tools, the best are PinkVERIFY™ ensuring the adequacy to support ITIL
processes. PinkVERIFY™ is an internationally recognized IT Service Management
(ITSM) tool suite assessment service (http://www.pinkelephant.com/pinkverify/).
Most of the times, ITIL tools are supported by more or less robust databases
(CMDBs). However, this kind of tools only supports ITIL in their service lifecycle
management processes. None of the vendors support both EA and ITIL.
The current state of the art needs to use different tools to work on EA and ITIL, with
the comprehensive view being diffused across these various tools, each supporting only
one or more aspects of the overall IT services landscape.
2.5.8 Synopsis of Related Work
After the review of the set of different approaches from related work, this section
presents the results focusing on the integration between EA (TOGAF) and ITSM
(ITIL). The published work that we analysed was classified according to a number of

59
criteria. Those criteria that we deem relevant were defined in order to satisfy a
comprehensive approach, able to integrate EA and ITIL. Those criteria are:
• Integration Mechanism – is related with the usability encompassing the
provisioning of rules for the integration’s adoption. This criterion should score
if the approach have usability and make us able to integrate EA and ITIL;
• Generalization – is concerned whether the approach encompasses a defined
version of the ITIL and/or a defined EA framework, or if the approach's
principles can have a widespread use;
• Modelling Guidance – is related with the approach’s capability to provide
modelling guidance of the integration issues;
• Concepts Validation – is related to the effectiveness of the approach in the
integration of adopted concepts as well as the semantic integration;
• Support Repository – is concerned with the provision of orientations to the
required support repository. If the approach foresees more than one repository
it is considered a lower result in the integration orientation.
A score was assigned to each approach in each criterion, based on an ordinal scale
depicted as a symbol: Lower/Basic +; Partial/Moderate ++; High/Plenty +++; Not
applicable/Without answer --.
Table 1 provides the synthesis of the analysis results.
Table 1 – Classification of the Different Approaches from Related Work
Related
work
Integration
Mechanism
Generalization
Modelling
Guidance
Concepts
Validation
Support
Repository
EA in the
ITIL Books
+ ++ + + ++
EA
Expansion
to Integrate
ITIL
++ + +++ -- ++
TOGAF
and ITIL ++ ++ + + +
Extending
EA
++ +++ -- + ++
Alignment
between EA
and ITIL
+++ ++ ++ + +
Shared
Repository
++ ++ + + +++
Tools for
EA and
ITIL
-- + + -- +

60
As can be seen in the previous Table 1 none of the analysed works has a high score in
the criteria rank. On the other hand, not a single criteria was essentially achieved.
Therefore, our approach should encompass all defined criteria based on the research
work's approaches that had better scores on some criteria.
2.6 ITIL METAMODELS
There are many publications and researches about metamodels. These metamodels
construct and refine the concepts in process domains, such as software development
(OMG, 2003b), configurable services (Heiskala, Tiihonen, & Soininen, 2005), security,
performance, and broader process framework (Shen et al., 2010).
However, research work or professional publications regarding the definition of an
ITIL metamodel is quite limited. Most of them focused on the previous ITIL version
(v2) and are mostly process-oriented, stressing few processes, without a holistic
description on how to generalize service lifecycle and neither defining universal
patterns nor conceptual models for ITIL’s concepts.
In the following sub-sections we present chronologically some of the most significant
research works in ITIL metamodelling.
Garschhammer et al. (2001)
One of the most comprehensive work in this field is the Munich Network
Management (MNM) service model (Garschhammer et al., 2001).
Garschhammer et al. recognizes the difficulty to apply ITIL without starting with a
given foundation. A detailed model giving an overview over ITIL was recognized as
missing. Thus, it is hard to see the connections between management processes and
activities described in different documents.
The aim of the MNM group is to provide a conceptual service metamodel, as “a generic
model defining commonly needed service-related terms, concepts and structuring rules in a general and
unambiguous way" (Garschhammer et al., 2001).
A top-down methodology was defined regarding the separation of service and its
implementation. The examination of the interactions to accomplish a service allows
the identification of customers and providers. By examining the interactions they were
also able to identify classes and roles as well as entities participating in services. The
MNM team demonstrated the application of MNM model on concrete service desk

61
scenarios and also discusses the service modelling in general (Garschhammer et al.,
2001).
However, despite the valuable work and the interesting methodology to identify
services, the functional classification of the resulting work was too focused on
telecommunications services not covering ITIL concepts.
Betz (2003)
Betz has developed an interesting work relating metadata with metamodelling. He
analysed and demonstrated the convergence of metamodelling. Metadata was defined
as the basic primitives that are used to build up a full semantics for defining
metamodels (Betz, 2003).
His work starts from a historic perspective on metamodelling up to the Object
Management Group (OMG), mentioned as the foremost group focused on
metamodelling. Besides other approaches special attention is given to IT Service
Management, especially along with the ITIL (Betz, 2003).
It is noteworthy the recognition that operational IT concerns have historically not
been part of metadata scope. In this sense, the metadata concept is missing relevant
key components to run IT. At best, metadata is an after-the-fact data that integrates
sources like CASE tools, operational systems, and others (Betz, 2003).
This missing metadata also emerge in a set of operational disciplines known as ITSM
with a special focus in ITIL. However, the ITIL’s existence of a CMDB encapsulating
Configuration Items (hardware, software, databases, documentation, and much more)
overlaps with the concept of metadata, which is not recognized in ITIL.
It is remarkable the assertion of Betz that “the definition of configuration items in a Service
Management Framework configuration management tool is in a sense metamodelling” (Betz, 2003).
However it is also recognized the capability to anyone with privileges to create, classify
and relate Configuration Items arbitrarily without regard to what makes sense
semantically.
The theory of Configuration Items lacks the ability to describe constraints, once no
normative metamodel is specified (Betz, 2003). Despite Betz elaborated some
interesting future directions, for alignment of ITIL, metadata, and metamodelling,
was not defined any conclusive proposal.

62
Jantti and Eerola (2006)
Jantti and Eerola (Jantti & Eerola, 2006) have a pioneer work on problem
management process metamodel, proposing a conceptual model which clarifies the
concepts within IT service problem management and connects these concepts to
traditional software engineering tasks, focusing on reactive problem management
(Jantti & Eerola, 2006).
However, the defined concepts were quite limited and only a part of problem
management was considered. The research was focused in ITIL v2 and the main
purpose was to describe the basic concepts of Problem Management process.
Strahonja (2009)
Based on Jantti work, Strahonja (Strahonja, 2009) makes an improvement proposing
the construction of an ITIL definition metamodel, from the ITIL glossary and other
specifications, in an object-oriented fashion by using structure diagrams conform to
UML notation.
However, their work is still very brief as the metamodel only covers some concepts
and supports management processes. On the other hand, some defined concepts on
Component Metamodel (CMM) do not exist in ITIL neither is clear how they were
created.
Different levels of concepts are treated jointly and it seems that his work was mainly
focused on ITIL v2 and only in Service Support (Strahonja, 2009). Still remains
needed a service-oriented approach using a generic set of concepts language
independent, contrary to UML orientation from Strahonja
Was made a practical application of this proposal without quantification,
formalization not eliminating subjective assessment. Despite the valuable work as an
abstract model of the ITIL’s theory, this proposal lacks on semantic and application
guidance.
Shen et al. (2010)
Shen, et al. (Huang, Shen, & Chen, 2010; Shen et al., 2010) presented an IT service
support process metamodel, extending a generic business process definition
metamodel (BPDM (OMG, 2003a; Huang et al., 2010)) and developing an IT service
support process engineering platform.

63
As a result, a two steps ITIL metamodelling method, was proposed based on the fact
that current standards and tools are not enough to provide precise, abstract and
systematic ITIL concepts (Huang et al., 2010; Shen et al., 2010). First, selecting an
appropriate business process metamodel, analysing ITIL’s processes and extracting its
abstract concepts from glossary and other specifications. After that, comparing these
entities with concepts of existing business process metamodels. The ITIL metamodel
was, therefore, a kind of business process metamodel.
However this research is focused on ITIL v2 and only in Service Support processes
not covering the overall ITIL.
Valiente et al. (2012)
Valiente (Valiente et al., 2012) presents an ontology approach to help service
providers defining semantics to their service management process models and detect
semantic ambiguities, uncertainties and contradictions. The proposed ontology is used
to specify constraints and infer new knowledge.
The Valiente’s Onto-ITIL encapsulates a model based in principles (Valiente et al.,
2012). Despite the valuable work, the proposal is mainly focused on ontology
definition and lacks on metamodel representation. However, her contribution is
valuable in the aim of translating ITIL expressing in natural language to a formal
representation.
Summary of ITIL Metamodel Approaches
The studies were classified according to a number of criteria, that we deem relevant
for being satisfied by a comprehensive approach, in order to define an ITIL
Metamodel. Those criteria are:
• Completeness – is related with the coverage of ITIL’s concepts and
processes.
• Generalization – is concerned with all versions of ITIL or if is focused in a
defined version.
• Semantic - is concerned whether the approach provides guidance that allows
modelling in different languages.
• Application – is related to the effectiveness suitability of the approach in
providing a widespread usability in different domains or if was defined to a
limited scope.
• Validation – is related to the effectiveness of the approach evidenced through
studies or in an operational application.

64
A score similar to the previous table was assigned to each work with a criterion based
on an ordinal scale depicted as a symbol: Lower/Basic +; Partial/Moderate ++;
High/Plenty +++. The following Table 2 provides the synthesis of the analysis results.
Table 2 – Classification of the ITIL Metamodelling Approaches
Study Completeness Generalization Semantic Application Validation
Garschhammeret
Al. + + + ++ ++
Betz + ++ + + +
Jantti and Eerola + + ++ ++ +
Strahonja ++ ++ ++ + +
Shen and Huang + + ++ ++ ++
Valiente et al. + + ++ ++ ++
Summarizing, as can be seen in the previous Table 2, none of the works address even
moderate/partially all the criteria. On the other hand, none of the criteria was
achieved in a high/plenty way.
Despite all valuable work regarding the definition of an ITIL metamodel we do not
identify a proposal focused on the current version of ITIL neither covering the defined
criteria that allows to define a metamodel. As defined by Guizzardi, a metamodel
should enable a description of a language’s abstract syntax in order to define a set of
constructs that grant the creation of grammatically valid models (Guizzardi, 2007).
2.7 SUMMARY
In this section we presented a set of concepts from the literature review and from
related work that contribute towards a conceptual foundation to this dissertation. The
review of literature and relevant topics of this research area allows a better
understanding of key concepts and issues that will be included in the proposal.
This research work encompasses Enterprise Engineering area as it relates multiple
organizations’ dimensions, such as processes, technology, people, and services, among

65
others. As in other engineering fields, this gives us a body of knowledge and best
practices to develop a creative application of scientific principles.
Enterprise engineering recognizes EA as the core representational element for the
representation, in layers, concepts and artifacts, of an organization’s systems and
properties allowing observation from different views and perspectives.
Different needs, scopes and authors have proposed different EA frameworks with
common principles like: modularity, holistic representation, relationships between
artifacts and concepts, and connection among layered architectures, such as business,
process, application, information and technological infrastructure.
From these frameworks, TOGAF has major relevance and widespread acceptance
motivating our research focus in TOGAF framework. TOGAF is a well-defined
framework despite some identified limitations.
To reduce conceptual ambiguity, share clarified knowledge, and increase the
definition’s accuracy in concepts representation it is necessary the use of ontologies.
Ontology definitions allow us to use models representing real-world situations.
Modelling languages are essential instruments for the description and communication
of architectures. From an overview of some of the most representative languages for
modelling EA, we identified ArchiMate as the language that best covers all domains,
namely business processes, applications, and technology.
SOA’s principles were presented as the best orientation to provide organizational
agility between layers, where the loose coupling characteristic of SOA’s agility works
as a basis for achieving architectural alignment.
We made an overview of ITIL as the de facto standard to IT service management,
involving layers and components common to the EA approach.
We also identified several common points between TOGAF and ITIL. For instance,
the Architecture Capability Framework (ADM) addresses the organization, processes,
skills, roles and responsibilities required to establish and operate an architecture
function within an enterprise. In ITIL, capabilities are intangible assets of an
organization, involving the ability of an organization, person, process, application,
configuration item or IT service to carry out an activity.
On the other hand, the modelling language of ITIL is a description in natural
language, while ITIL processes are usually depicted as well defined sequences of
activities by flow charts. The representations to describe ITIL domains seem to lack a
common, clear and formal notation and semantic.

66
From the related work, and from the Table 1 – Classification of the Different
Approaches from Related Work, we did not identify any approach solving the
integration problem between EA and ITIL.
Some organizations may be tempted to extend the database schema of their CMDB,
especially since some vendors provide tools to allow the CMDB model to be extended.
This would allow adding new tables and views. Hypothetically, a CMDB could be
also used to store the architectural assets of EA. The extension of CMDB's metamodel
could integrate the missing information related to the enterprise architecture.
However, the problem of keeping different teams working in the same field from
different perspectives and principles remain. On the other hand, the scope of a
CMDB is quite limited, only covering Configuration Items. A CMS has a wider scope
covering all the concepts deemed needed to integrate an EA. Nevertheless, we did not
identify any related work addressing CMS issues.
Finally, it was conducted a review regarding ITIL Metamodelling research works. It
was concluded that none of the research works addressed essentially all the criteria to
define an ITIL Metamodel.
Summarizing, the integration between TOGAF and ITIL makes sense since both
frameworks cover and relate common subjects. This integration implies the
identification of an ontology allowing the common understanding. However, this
subject remains a non-solved problem. In the next section, we compare TOGAF and
ITIL identifying the differences and complementarities.

67
3 COMPARING TOGAF AND ITIL
In this section we start with an overview comparing TOGAF and ITIL, followed by
the integration proposal itself in the following section.
TOGAF and ITIL are both frameworks that follow a process approach. However,
ITIL was developed to support IT service management and TOGAF was developed
to support organizations in the development of enterprise architecture. The focus of
ITIL is, therefore, on services, whereas TOGAF is focused on architecture.
There are a lot of references to architectural concepts in the ITIL books of the current
version, hitherto only found in publications related to enterprise architecture. The
same, although in a lesser extent, applies to TOGAF, where we find references to IT
management. This coverage overlap is explicitly mentioned and described in
TOGAF.
However, EA teams, and consequently TOGAF teams, are only slightly involved in
ITIL deployment, and vice-versa. The main reasons are (Peyret, 2011b):
• The ITIL “strategy” and “design” process domains are less frequently
implemented and have the lowest priority in traditional IT service
management initiatives;
• ITIL recognizes only a limited role in EA. Only since ITIL V3 was identified
the role of enterprise architect, only in the design domain, and only limited to
IT architecture;
• The drivers for ITIL adoption do not tend to leverage EA involvement;
• EAs themselves report only limited involvement in ITIL deployment.
TOGAF is directly related to ITIL domains and the above-mentioned overlap is not
the same along frameworks. Figure 27 shows TOGAF and ITIL scopes and the
position of both to achieve strategic alignment.
Figure 27 –TOGAF and ITIL alignment, adapted from (Sante & Ermers, 2009)
TOGAF (Enterprise Architecture)
ITIL (IT Service Management)
Business
Architecture
Information
Architecture
Technology
Architecture
IT Solutions IT Services
Business
strategy
Outcomes
Are outcomes aligned with strategy?

68
Business architecture is addressed by TOGAF but not directly by ITIL and, similarly,
IT services are principally addressed by ITIL but less by TOGAF. The other elements
(information architecture, application architecture, and technology architecture) are
covered in both frameworks, although the level of detail differs in each framework.
Both approaches contain a quality loop based on an extended version of Deming’s
quality cycle; in TOGAF it is referred to as the “Architecture Development Method
(ADM)” and in ITIL it is dubbed the “IT Service Lifecycle”. However, these loops do
not overlap completely.
Another similarity between these frameworks is that they both originated from IT,
thus explaining why the integration of both frameworks with the business is not yet a
common practice.
In addition, both frameworks are sets of best or good practices, but the activities
described in TOGAF are not covered by ITIL. A careful reading shows that,
especially when it comes to architectural activities or concepts, the ITIL theory on
architecture is not so coherent as in TOGAF.
In summary, TOGAF gives the IT solution and monitors the EA building, but it does
not provide guidance on how to deliver IT services. ITIL gives the delivery of IT
services but without a definition on the supporting architectures (Sante & Ermers,
2009). ITIL encompasses the concerns on information and technological architectures
but the business architecture is left out and therefore the linkage between the business
and the IT.
The following sections present TOGAF along ITIL books, highlighting the principal
similarities and differences between the two approaches.
3.1 SERVICE STRATEGY
The value of IT comes from the value added by IT services for the business. Service
Strategy specifies the service requirements and defines how they will be fulfilled from a
technical and organizational perspective. It provides guidance on how to design,
develop, implement and maintain service management as an organizational capability
but also with strategic value.
Service Strategy, in more recent versions of ITIL, fills the gap of ITIL V2 for IT
Governance but also introduces all requirements to defining an EA (Nabiollahi &
Sahibuddin, 2008). The Service Strategy book is concerned with prerequisites for

69
building a service management system, focused on organization’s objectives, policies
and guidelines.
Service Strategy is comparable to TOGAF with subjects found in the ADM, more
precisely in the Preliminary Phase (Phase A) and the delivery of business architecture
(Phase B). However, the development of business architecture has a difference
between TOGAF and ITIL. The business architecture is part of the TOGAF
framework and obtained from ADM’s Phase B. The scope of ITIL at Service Strategy
level is limited to develop an effective and efficient service management system, whilst
developing a business architecture is out of scope of ITIL (Sante & Ermers, 2009).
At high-level the most important output from the ITIL’s Service Strategy stage is the
identification and definition of services to be offered. The service identification implies
an identification of stakeholders’ needs, which is very similar to the business
architecture generated by TOGAF ADM that identifies what will help stakeholders to
benefit most from the services generated. In both approaches, service identification
and definition is an important output.
Once the similarities between TOGAF and ITIL have been identified, from the
identification of services developed under the strategic planning, we can use ITIL
processes to manage these services throughout their lifecycle. Effectively, the purpose
is to identify what service management processes should be included in the service
management system used by TOGAF. Appendix F – ITIL Artefacts and Processes
(Figure 116) presents an overview of ITIL’s processes.
TOGAF needs to be fully engaged with ITIL processes, especially change, asset and
configuration management as the processes that ensures the information related with
EA and keep it updated. This represents a significant obligation over and above
normal operating duties for the EA.
On the other hand, often an architect is involved in all area of Service Strategy
including the elements of costs and risks and also the financial management. These
requirements developed through Service Strategy should be deployed into operations.
This reinforces the need to integrate Service Strategy into TOGAF, and thus arguing
the integration proposal between approaches.
As a result, we should be able to apply ITIL standards and best practices of service
delivery to TOGAF reflecting organizations’ strategy, its objectives and goals.
TOGAF crosses the boundary of ITIL’s strategy and design, but ITIL should
encompass all dimensions and perspectives of TOGAF.

70
3.2 SERVICE DESIGN
Service Design is the ITIL lifecycle book that crosses over most significantly TOGAF
(Sante & Ermers, 2009). The content of ITIL’s Service Design book is focused on
designing new or changing the existing services, based on the strategy prerequisites as
defined in Service Strategy. Similarly, the collection of requirements as defined in
TOGAF’s Requirements Management is covered in Service Design. However, the
ITIL documentation for Service Design identifies only IT architecture management
as a process that involves EA.
Service Design covers objectives of TOGAF when one of the goals state that design,
developing and delivery of any IT service should lead us to prepare or produce
required infrastructure, environment, applications and data/information resources
(Nabiollahi et al., 2010). Most of these architecture aspects, which are emphasized in
Service Design, are part of EA concerns and deliverables. Service Design also
produces some parts of TOGAF outputs.
We can state that architecture design constitutes an important activity within Service
Design as we can see in several places throughout the Service Design. Moreover, in
Service Design references to TOGAF and other architecture frameworks are also
made.
On the other hand, the architecture design has much in common with Service
Strategy’s service definition, identifying and including anything that could contribute
to the delivery of a service, namely assets such as management, organization, process,
knowledge, people, information, applications, infrastructure, and financial capital.
We can identify five architectures in ITIL (seed Figure 21 on pag. 50): service
architecture, environmental architecture, application architecture, data/information
architecture, and IT infrastructure architecture. One of the major differences between
the frameworks is that TOGAF addresses the business architecture in Phase B. The
business architecture seems to be out of scope of ITIL in which architecture translates
applications, infrastructure, organization, and support activities, providing an
integrated approach to deliver a set of services to the business, but considering the
overall architectures and not an independent architecture.
The activities performed in TOGAF Phases C and D, respectively data and
technology, bear a great resemblance to activities described in Service Design, as both
frameworks are about designing data architectures, application architectures and

71
technology architectures. The environmental architecture, which is mentioned in
Service Design, does not seem to have a counterpart in TOGAF.
Finally, neither business designers nor enterprise architects usually design services.
Without service design, we cannot put architect ideas in practice. This is why one of
the risks behind TOGAF are services that have not been correctly carried into service
management, as Service Transition should do.
3.3 SERVICE TRANSITION
The activities described in Phases E, F and G of TOGAF can also be found in Service
Transition. However, TOGAF is only concerned with architectures’ design, and
planning the migration of those architectures. On the other hand, in ITIL, the scope
of the Service Transition activities is much broader, with activities that include the
building, testing and planning of the desired IT solution. On the other hand, we may
argue that the scope of TOGAF is broader than the scope of ITIL as it includes the
business architecture.
Although TOGAF states that implementing IT operations is an activity carried out in
Phase G, which includes the IT service delivery implementation, what that exactly
means is not elaborated in TOGAF.
A simple view of the inter-relationships of Service Transition processes is summarized
in the Figure 28. Considering all type of changes along EA concepts, beyond
operational changes, changes in business and IT services are important issues.
A key principle of Service Transition is to carry out any change as an essential part of
improving IT services for an organization on a continual improvement basis,
considering that all changes must be recorded and managed in a controlled way.
Figure 28 – Service Transition Relationship, adapted from (Lea-Cox, 2013c)
Service Transition
Change
Management
Release and
Deployment
Management
Service
Validation
Change
Evaluation
Knowledge
Management
Enterprise Architecture Repository
Service
Conﬁguration
Management

72
One of the major differences between TOGAF and ITIL is in change management.
TOGAF’s Phase H (Architecture Change Management) does not predict the change.
Instead, after a change is formally made, a new architecture evolution cycle initiates:
“When changes are identified, change management will determine whether to formally initiate a new
architecture evolution cycle” (Sante & Ermers, 2009).
It is important to consider the definition of change in ITIL as “the addition, modification
or removal of anything that could have an effect on IT services” (Cabinet Office, 2011f). We
highlight that “anything” should mean not only the components of an IT service, but
also changes that somehow are related to IT services, namely business services.
The scope of change using the definition above is potentially wide. However, this
meaning is not translated in ITIL processes, where changes are only related to IT
services. This suggests that we should start by considering as changes whatever lies
outside the limited scope of ITIL change management process. Therefore, we should
consider as changes in Service Transition:
• The usually scope of IT service change in the Service Portfolio;
• All business services not categorised as IT services;
• Architectural changes as usually considered through TOGAF ADM; and
• New or changes in existing artifacts.
Thus, the focal point of change management should be in objectives from changes in
strategy, business services, IT services, and artifacts, but also in architecture. In this
context, changes do not happen in isolation but they affect other (related) components
in the organization’s supply chain.
So, change management processes must be synchronised with the organization, and
also with suppliers and third party service providers. For example, changes not only
introduce new IT services, retire old IT services and change existing IT services, but
the last category can include the transfer of IT services between third party service
providers and between the IT organization and third party service providers. Changes
can also be made to upgrade the organization’s Service Management System.
If change evaluation was implemented, then we could determine feasibility and
acceptability through the evaluation of the change proposal, with the assistance of the
Configuration Manager, to identify the impact of the change proposal on the (IT)
organization and to update the Enterprise Architecture Repository when change
occurs. If the change proposal is approved, then service portfolio management is
authorized to initiate the service design processes.

73
In ITIL, a release is defined as a set of one or more changes. In the context of our
work, the difference between release and change is not important and, therefore, we
consider as “change” both concepts.
Service configuration management ensures that the identified configurations under
the control of the organization are supervised throughout their lifecycle. This includes
maintaining information about configurations and the relationships between them.
The main objective of configuration management is to define and control service and
infrastructure components and to maintain accurate configuration information.
Concerning IT infrastructure and services efficient control, configuration
management plays a fundamental role providing accurate information to all service
management processes. In business-driven IT management context, this closed
relationship includes the interaction among main agents belonging to this context,
such as business, people, processes, tools and technologies (Baioco et al., 2009)
A configuration model is a concept, which is not well defined in the ITIL Service
Transition book. The configuration model establishes that configuration management
delivers a model of the services, assets and infrastructure by relating them and
defining a logical model of services and infrastructure in a model as a single
representation, which can be used by all parts (finance, HR, customers, IT services,
etc.).
In this context, the concept Enterprise Architecture Repository extends the
Configuration Management System (CMS). The CMS has a wider scope than CMDB
and includes tools for collecting, storing, managing, updating, analysing and
presenting data and information that are used to support all Configuration Items and
their relationships. The concept of Enterprise Architecture Repository should have a
key part on the CMS environment, including the architectures (as Business
Architecture) all the diagrams pertaining to Services, their structure and their
relationships.
3.4 SERVICE OPERATION
Service Operation has been the main focus of ITIL in the previous versions and ITIL
having mature processes related to IT operations. On the other hand, TOGAF does
not provide guidance related to this aspect of the IT Service Lifecycle, other than
stating that guiding the development of IT operating models and implementing IT
service delivery are activities carried out within TOGAF (Sante & Ermers, 2009).

74
Another main difference between TOGAF and ITIL is running IT operations and
delivering IT services. While IT services delivery and operations are within the scope
of ITIL, TOGAF does not cover the development and maintenance of a run time
environment. In fact, how services are actually produced and delivered is not covered
in TOGAF at all. After an IT solution has become part of the operational
environment, it turns into (part of) one or more services, with which TOGAF is not
concerned (Sante & Ermers, 2009).
3.5 CONTINUAL SERVICE IMPROVEMENT
The Continual Service Improvement (CSI) phase of ITIL provides a very detailed and
extensive guidance of a seven-step improvement process, which provides guidance on
how to measure, report, plan, and operationalize improvements on both tactical and
strategic levels.
CSI bears a great resemblance to Phase H of TOGAF (Architecture Change
Management), which address this topic from a more theoretical viewpoint, with lower
detail. However, TOGAF states that if change management processes are already in
place (e.g. ITIL change management), they could be used for, or adapted to,
managing changes to the architecture (Sante & Ermers, 2009).
3.6 SUMMARY
TOGAF and ITIL have much in common, despite some differences. TOGAF
describes a consistent process to define a business architecture and the complementary
architectures, despite the lack of output clarity on business architecture.
ITIL’s Service Strategy provides and defines the inputs for Service Design. The ITIL
processes for managing Service Transition ensure the lifecycle of all changes to be
made with minimum disruption to customers, namely the planning, configuration,
deployment, validation, and evaluation. The ITIL Service Design is a book with
processes that puts ideas into practice, identifying the services built and tested through
Service Transition.
Summarizing, TOGAF guarantees a consistency for the design and deployment of
new products and services addressing business requirements. ITIL guarantees the
consistency of services between them through the use of standard processes, such as
change management.

75
One of the main differences between TOGAF and ITIL relating to change is that
TOGAF is mainly focused on architectural changes and does not predict change.
However, no matter what organization type, the changes can be “anything” and are
always occurring at some organizational level, and should be treated and considered
along the same process. Change management processes must be synchronised within
the whole organization, along all layers, artifacts, and relationships.
Finally, Service Operation is the ITIL main focus, where TOGAF does not provide
related guidance and therefore only ITIL processes allow the use of an EA in a day-to-
day basis.
In this section we did an overview of TOGAF and ITIL relationship identifying the
largest differences and much of what they have in common. In the following section
we will verify the integration between the two approaches in our proposal.

77
4 PROPOSAL
In this dissertation we propose an ITIL metamodel that models the
integration between TOGAF and ITIL using the same language.
From the problem description we identified a lack of suitable solutions. This section
corresponds to the “Define objectives of a solution” and to the “Design and
Development” steps of the DSR Methodology, where we explain our approach and
propose a solution to integrate TOGAF and ITIL.
The proposal was developed using the EA definition, as a coherent whole of
principles, methods, and models, in the integration of TOGAF and ITIL. We will
achieve the four DSR artifacts: constructs; models; methods; and instantiations
(March & Smith, 1995; Hevner et al., 2004): Constructs as the “language” specifying
problem and solution; Methods describing the processes and providing guidance on
how to solve the problem; Models using the language to represent the problems and
the solution; Instantiations as a problem-specific solution achieved. Figure 29 shows
the followed path.
Figure 29 – Proposal’s Sequence
Hence, throughout this section we will present the steps followed along our proposal.
First we identified the core concepts from both approaches, following EA principles,
focusing on TOGAF and showing how ITIL concepts relate to ArchiMate. After that,
we integrated the concepts from both approaches finding the common ones and
solving concepts duplication.
As the ArchiMate is used to model TOGAF (Open Group, 2012), if we could use
ArchiMate to model ITIL, we could integrate TOGAF and ITIL using the same
language.
Since ITIL does not have an ontological relationship between concepts, we propose
an ITIL metamodel to model TOGAF and ITIL using the same language.

78
We also propose a set of ArchiMate viewpoints enabling stakeholders to focus on
particular aspects of the architecture related to IT service management, and finally,
we will use our proposal to model ITIL using ArchiMate.
The solution integrating TOGAF and ITIL encompasses the EA principles with
referred architectures and the relationship among them, following ITIL service
lifecycle management processes.
Our solution allows the mapping and visualization of the organization’s actual state,
top-down and bottom-up. This is equivalent to the EA’s “as-is” model and allows,
from ITIL principles, ensuring service delivery through all architectures.
The main goal of this dissertation is to integrate TOGAF and ITIL with a formal
representation. To achieve this, we should clarify if it “makes sense to integrate
the two approaches” answering our first research question.
Once verified the integration feasibility we will define “how to integrate the two
approaches and which is the integration path” answering the research question
number two.
It is desirable to model an architecture in a standard language, enabling an approach
describing the architecture semantics and their re-use among different tools (Open
Group, 2011). As we saw, in a context of TOGAF, ArchiMate is a modelling language
that allows to describe architectures through metamodels relating concepts, and
providing the needed models and views. This language will act as a glue between
TOGAF and ITIL.
ITIL should have the necessary concepts to be fully represented in ArchiMate.
Therefore, we will define a metamodel to ITIL and concepts specialization using
ArchiMate. This metamodel will answer the third research question “How to
represent the integration between the two approaches and, especially,
their relationship?”. ITIL does not have a commonly accepted metamodel, so it
will be a valuable contribution to this area.
We will answer the fourth research question “Considering the effort and
magnitude needed to build and maintain coherent information, how to
keep the integrated information up-to-date and operationally usable on a
daily basis?” with ITIL’s processes to keep the updated TOGAF information useful
in a day-to-day basis.

79
4.1 INTEGRATION CRITERIA
In order to integrate two different frameworks they must be at the same level. The
integration between EA and ITSM is possible if we integrate two frameworks at the
same abstraction level. The integration between EA and ITSM should be developed
using the same level of abstraction. For example, we cannot combine or even compare
EA and ITIL because they represent different abstraction levels and different realities.
While EA is a set of principles, ITIL is a well-defined framework to manage the IT
service lifecycle.
Therefore, EA is to ITSM as TOGAF is to ITIL, and we integrate ITSM and EA
through the integration of TOGAF and ITIL. We chose TOGAF as the EA
framework and ITIL as the ITSM framework because, as we saw, they are the most
widespread used frameworks in both approaches (Hochstein et al., 2005; Braun &
Winter, 2007; Correia & Abreu, 2009; Sante & Ermers, 2009).
The following Table 3 synthesizes the alignment between the different levels of
abstraction.
Table 3 – Alignment Between Abstraction Levels
Body of Knowledge EA ITSM
Framework TOGAF ITIL
Modelling
Language
ArchiMate
Ad-hoc models,
BPMN
Tools
Archi, System
Architect Enterprise
Architect, ARIS (…)
EasyVista, BMC
Remedy, HP Service
Manager (…)
The major difference between TOGAF and ITIL is that to the former the central
objective is the development of a fairly stable EA and the last is managing on-going
services.
Integrating TOGAF and ITIL allows us using ITIL’s processes along TOGAF
development. On the other hand, integrating both approaches we should be able to
model ITIL using the same language, ArchiMate in this case.
ArchiMate (Lankhorst, 2009) seems to be such language, since ArchiMate is a
language for modelling EA as used in TOGAF, and if we can use ITIL in the

80
Architecture Capability Framework, Enterprise Continuum and Architecture Content
Framework, we should be able to use ArchiMate to model ITIL.
Thus, as TOGAF is the basis for EA development, the ITIL processes should be
integrated into TOGAF using ArchiMate as the common language as illustrated in
Figure 30.
Figure 30 – TOGAF and ITIL Integration
We defined an integration criteria based on the factors that are responsible for the
difficulty to integrate both approaches. We analysed these criteria to each framework
separately to identify the strengths and weaknesses of each approach.
We defined the following criteria to an effective integration between TOGAF and
ITIL approaches:
• Modelling language – is related with the framework modelling capability to
and guidance to provide model creation;
• Management processes – is related with the processes definition
encompassing the framework usability and exploration;
• Tools and repository – is concerned with the orientations to the provision
of the required support repository and tools to support framework;
• Dedicated teams – is related with the necessity of dedicated teams to
develop and support the framework;
• Defined concepts – is related to the effectiveness of the framework in
concept’s definition;
• Completeness of solution – is related with the effectiveness in provision
alignment between business and IT.

81
A score was assigned to each framework, based on an ordinal scale depicted as a
symbol: Lower/Basic +; Partial/Moderate ++; High/Plenty +++. We synthesized
the results of criteria analysis in the following Table 4.
Table 4 – Criteria to Integrate TOGAF and ITIL
Criterion TOGAF ITIL
1. Modelling language +++ +
2. Management processes + +++
3. Tools and repository ++ ++
4. Dedicated teams ++ ++
5. Defined concepts +++ +++
6. Completeness of solution ++ ++
The major differences between frameworks are in the well-defined modelling
language for modelling TOGAF and the overall management processes from ITIL.
We will base our integration considering the combination of these both criteria.
From Table 4 we conclude that higher marks are on “Modelling language” from
TOGAF, “Management processes” from ITIL, and “Defined concepts” on TOGAF.
Since we have already defined ArchiMate as the modelling language, and the ITIL
management processes as the ones that best enable us to a complete service
management lifecycle, we should concentrate our efforts on integrating concepts from
TOGAF and ITIL. We will use TOGAF as the modelling grammar.
4.2 INTEGRATION VERIFICATION
When designing architectures, architects should use a common, well-defined grammar
to avoid misunderstandings and promote clear designs (Lankhorst, 2009).
To understand and characterize concepts, we should start by defining them. As
mentioned in Section 1.4.1, we follow the ontology engineering process methodology
(Ostrowski et al., 2012) to identify terms, create and relate concepts.
We started by identifying a set of concepts, keeping the ones common to TOGAF and
ITIL, with a strong relation to main concepts within a domain. A set of concepts used

82
to describe an architecture is frequently used as ontology within modelling (Lankhorst,
2009).
Moreover, the relationship among those concepts should be based on an ontological
reference. A defined ontology with a set of concepts relating the two approaches will
be a common frame of reference.
After the concepts identification we defined their properties. Then, we distribute
concepts along EA layers. Finally, we defined the relationship between concepts,
through a conceptual map of the integration between TOGAF and ITIL approaches.
In this section, we present the aggregation of relevant concepts for the integration
proposal. Following the ontology engineering process methodology, we identified the
core terms of TOGAF, ITIL, and SOA. After that, we integrated those terms in a
single frame. Then, we identified properties and constraints and defined our concepts,
which are related in a conceptual map.
4.2.1 EA Terms and Concepts
Most of all, EA frameworks have in common principles such as (Lankhorst, 2009): a
holistic representation of organizations; views and the ability to map relationships
between artifacts and architectures; the independence and connection between
layered architectures; and documentation of the “as-is” organization’s architectures.
Architecture identification should be considered a fundamental step to understand
whether its elements are aligned and in readiness for any challenge. The EA
correction results from a continuous process of representation, and maintains the
elements required to align organization governance (P. Sousa et al., 2006).
A decomposed representation of different EA, whatever the framework or approach,
establishes in some way the relationship in the generic views and with the concepts.
From different authors and contributions we developed the aggregation of concepts
along the architectures as presented in Figure 31 (Spewak & Hill, 1992; Vieira et al.,
2004; Bernard, 2005; Schekkerman, 2006; Vasconcelos, Sousa, & Tribolet, 2007;
Winter & Fischer, 2007; Nakakawa, 2008; Lankhorst, 2009; Nabiollahi et al., 2010;
Gama, Mira da Silva, et al., 2011; Open Group, 2011).
Although some architectures are presented as integrated (for instance business
architecture covering organization architecture and processes architecture), the
decomposed representations of EA in organizational layers usually share the following
architectures:

83
• Business Architecture – resulting from the definition of strategic
objectives, functional requirements, governance and deals with the
materialization of the business strategy into business processes;
• Organization Architecture – deals with aspects of the organization that
are directly related to the specificity of the business and its operations;
• Processes Architecture – showing how activities are organized to develop
the expected services, and describing the business processes to execute the
organizations’ strategy;
• Information Architecture – focusing on the required data for business
objectives, services and management of resources, also describing the
structure of an organization’s logical and physical data assets as well as data
management resources;
• Application Architecture – focusing on the deployment, development and
implementation of applications needed to fulfil the organization requirements,
providing a viewpoint for the individual application systems deployed, their
interactions, and relationships to the organization’s core business processes;
• Technological (Infrastructure) Architecture – providing the support to
applications, information and business processes, describing the infrastructure
intended to support the deployment.
The concepts’ definition is presented in Figure 31 (the detailed concepts’ definition is
presented in Appendix C – - EA Definitions and Core Concepts.
On each architecture layer, models differ in degree of aggregation, specialization, and
purpose. Therefore, different views often reflect different interests and needs for
different stakeholders, such as managers, software engineers, or network personnel
(Lankhorst, 2009).
Whatever the framework or approach, they have different perspectives, corresponding
to different views, linked and related as illustrated (Figure 31), with common aspects:
in every framework, we must be able to make decisions about the referred essential
dimensions, that is, business, processes, information, application, and technology
infrastructure (Schekkerman, 2006; Nakakawa, 2008).
The alignment between architectures takes on particular relevance, and EA is what
integrates each of these into a cohesive framework in order to obtain a coherent
“view” of the organization, which is then used for governance of its processes and
systems (C. Pereira & Sousa, 2004; Gama et al., 2007; Rohloff, 2008).
A view is a representation describing the deployment of an architecture from
the perspective of a related set of concerns.

84
Figure 31 – Enterprise Architecture Metamodel
In short, organizations’ benefits of EA result from having a clear understanding of its
structure, services, operations, processes, technology, and the web of relations tying
these together and connecting the organization to its surrounding (Lankhorst, 2009).
4.2.2 TOGAF Content Metamodel
The TOGAF content metamodel, illustrated in Figure 32, has much in common with
the Enterprise Architecture Metamodel (Figure 31). Organizational architecture and
process architecture are integrated in business architecture, although the relative
concepts remain, as well as the relationship among them.
A process in TOGAF describes an activity sequence from an event with interactions
between functions and services, but cannot be physically deployed. All processes
describe the flow of execution for a service, and the deployment of a process is
through the service it supports; i.e., an application implements a service that has a
process, but an application does not implement a process.
Communication network
Communication system
Database
Hardware
Infrastructure components
Infrastructure service
Platform
Platform service
Repository
Technological Architecture
Artifact
Conceptual data-model
Data
Information
Logical data-model
Meta-data
Meaning
Information Architecture Application
Application component
Application function
Application interface
Application platform
Application service
Application software
Application Architecture
Activity
Business event
Business function
Business object
Business process
Process Architecture
Organizational service
Organizational structure
Procedure
Role
Stakeholder
Task
Actor
Organization Architecture
Business service
Contract
Goal
Mission
Objective
Strategy
Business Architecture
support support
implemented byuses
supportdrives
deﬁnes

85
Figure 32 – TOGAF Content Metamodel, adapted from (Open Group, 2011)
In TOGAF a function describes units of business capability at all levels of granularity.
Any bounded unit of business function should be described as a function (Open
Group, 2011).
Business services support organizational objectives and are defined at a level of
granularity consistent with the level of governance needed (Open Group, 2011). The
granularity of business services is dependent on the focus and emphasis of the
business. Business services are conducted and supported by IT onto application
components. Application components can be hierarchically decomposed and may
support one or more processes, and therefore one or more business services.
A suite of technology components implements an application component. For
example, an application, such as ‘‘HR System’’ would typically be implemented on
several technology components, including hardware, application server software, and
application services.
4.2.3 SOA Principles in Integration Efforts
Following the adopted description of service (Section 2.3) “as a unit of functionality that
some entity makes available and has some value, if used, for others entities in layered services”, we
used the SOA paradigm to establish the relationship among elements and
architectures, allowing the implementation of ITIL processes, and mapping the
integration between the two frameworks (TOGAF and ITIL).
We identified SOA elements from different sources, (Eriksson & Penker, 2000;
OASIS, 2006; Open Group, 2009; Alwadain et al., 2011) as presented in the
Appendix E – - SOA Elements.
SOA principles cover both organizational and technical aspects of an organization,
and are based on the understanding of business capabilities as services, down to the
Business Architecture
Motivation Function
Business Service
Organization
Unit
Actor
Process
Event
Activity
Role
Technology Architecture
System
Infrastructure service
Technology components
Platform services
Communication
Information Systems Architecture
Information Application
Component
Service
Function
InterfaceData entities
Logical data
Data
components

86
technical implementation of encapsulated software capabilities (Alwadain et al., 2011).
Therefore, SOA principles and elements should be used in the conceptual modelling
of EA.
We considered the different layer granularity from SOA principles, where a layer
provides services to the other layer as illustrated in Figure 33.
Figure 33 – Layered Provision of Services
IT services integrate the technology and application services that are translated in
business services. Business services are provided by service providers and realized by
defined actors ensuring roles. The service functions aggregate IT processes that are
used by a defined service policy and its respective description, which constitute the
processes conducted by business services.
4.2.4 ITIL Concepts
The main ITIL concepts and definitions are presented in Appendix F – - ITIL
Artefacts and Processes (Cabinet Office, 2011b, 2011d, 2011f, 2011e, 2011c). ITIL
also has a layered relation between domains as illustrated in Figure 34. Services are
defined at a strategic level. Defined services are designed and passed to the operations
level through a transition phase. Services are continuously submitted to a continual
service improvement.
The ITIL service lifecycle concept, described in ITIL books (which have the
represented characteristic colour predominance), is developed as follows:
• Service Strategy (green) addresses where, why and what services should be
done;
• Service Design (dark purple) defines how to meet strategic definitions,
translating product/services into services;
translated in
deliver
realizes usestranslates
realizes
realized by
provides
Products/
Services
delivered by
used by
Business
Services
IT Services IT Processes
ProcessesService
Provider
IT Service
Provider
provided by
realized by

87
• Service Transition (dark orange) services are deployed into operations
and related processes;
• The operational day-to-day activities are treated by the Service Operation
(white blue);
• Continual Service Improvement permanently addresses the gap analysis
between current and desired states.
Figure 34 – ITIL’s Service Layer Relation
However, while ITIL does not provide an explicit method to go from service strategy
to service design, enterprise architects have methods to be followed (as TOGAF’s
ADM) relating all available information to figure out the needed interfaces through
the design process.
4.2.5 Relationship Between Concepts
We started by identifying a set of concepts, artifacts, and documents, keeping the ones
common to ArchiMate (as the TOGAF modelling language), SOA, and ITIL, and
distributing them along EA layers, identifying relations between main concepts.
We developed this analysis centred in EA since TOGAF integrates organizational
architecture and process architecture in business architecture, but keeping the
concepts. On the other hand, TOGAF has a defined modelling language.
The defined relation among concepts and architectures is established through services
using SOA principles, allowing the implementation of ITIL processes, and mapping
the integration between TOGAF and ITIL.
Then, from the identified concepts, we identified the interfaces, keeping the loose
coupling characteristic from SOA.
Service Operation
Service Transition
Service Design
Service Strategy
Continual
Service
Improvement
Service
Creation

88
However, if we considered the relationships among SOA elements in TOGAF
(Alwadain et al., 2011), and among the core artifacts of TOGAF with cross-layer
views in different frameworks (Winter & Fischer, 2007), we may introduce the main
ITIL concepts and management processes to define alignments between the different
approaches.
Besides distributing ITIL concepts from different layers, we also colorized them in
accordance to ITIL books. The results are shown in Table 5 (TOGAF’s business
architecture encompasses the layers of business, organizational and process from the
layers of the Enterprise Architecture Metamodel).
We mapped ITIL to TOGAF bridging concepts between the two approaches to show
how closely they are related along layers. We analysed the terms and concepts, as they
seem to represent, and we can see that similar concepts coexist in the same layer.
Therefore, having EA as the basis for an organization’s representation, through
different and independent architectures, we can map the service lifecycle with
architecture relationships.
The next step was the identification of key concepts applied to the selected domain.
These concepts were listed and should be established the relationships between them,
constructing a preliminary concept map that includes concepts in the list (Novak &
Cañas, 2008). It is important to notice that all concepts in the defined domain are in
some way related to another, and therefore it is necessary to identify the relationships.
To clarify the relationship among concepts, we used a graphical representation,
allowing the easy recognition of the relationship among concepts in different
architectures or views.
Graphical representations, as explicit representations, help in systematizing and aiding
engineering and complex systems design (Shanks et al., 2003; Zacarias et al., 2007;
Gama, Silva, et al., 2011).
In the next section, we present a conceptual map relating concepts graphically as “a set
of propositions or statements expressing a relationship between constructs” (March & Smith, 1995;
Vaishnavi & Kuechler, 2007).
The term “construct” has its origin in the active character of human perception
(Schuette & Rotthowe, 1998). Construct of an ontological model refers to a specific
construct of the ontology used in the ontological model (Fettke & Loos, 2003).

89
Table 5 – Relation of Concepts (ArchiMate/TOGAF, ITIL and SOA)
Layers from
Enterprise
Architecture
Metamodel
Core ArchiMate
concepts
(Appendix B)
SOA elements
(Appendix C)
ITIL concepts
(Appendix D)
Business
Value
Product
Contract
Meaning
Business Service
Actor
Business Interface
Business Service
Measure
Contract
Service
Service Consumer
Service Description
Service Function
Service Interface
Service Policy
Service Provider
Agreement
Business Customer
Business Service
Client, User, Customer
Contract
Governance
Job Description
KPI
Metric
Objective
Role
SLA
Service Portfolio
Service Provider
Strategy
Organization
Business Role
Business Actor
Business Collaboration
Business Interface
Location
Stakeholder
Processes
Business process
Business function
Business Interaction
Business Event
Business Activity
Activity
Business Process
Dependency
Function
IT Service Provider
Procedure
Process
Information
Business Object
Representation
Data Object
Asset
Attribute
Category
Configuration
Configuration Item
CMS/CMDB
DML
Application
Application Service
Application Function
Application Interaction
Application Interface
Application
Component
Application
Collaboration
Application Interface
Application Service
Application
Description
Application Policy
Application
Technology
Infrastructure
Artefact
Infrastructure Service
Infrastructure Function
System Software
Infrastructure Interface
Node
Device
Communication Path
Network
Infrastructure Policy
Infrastructure
Interface
Infrastructure
Description
Component
IT Infrastructure
IT Service
Resource
Server
System

90
4.2.6 Concept Map
Concept maps is a powerful tool for capturing, organizing, representing, structuring,
sharing, and keeping knowledge, but also a powerful tool to create new knowledge
(Novak, 1990; Anderson, 2006; Novak & Cañas, 2008).
The fundamental idea behind concept maps is that knowledge takes place by
assimilation of concepts and propositions into a cognitive structure, as a mental
process people use to make sense of information.
Beyond a knowledge representation, one of the powerful uses of concept maps is his
use as an evaluation tool (Mintzes, Wandersee, & Novak, 2000). Concept maps
develop high levels of cognitive performance and therefore they can also be used as a
powerful evaluation tool (Edmondson, 2000)
The importance of graphical representation falls into human capacity to process
information. While the “working memory” of a human is limited to process a
relatively small number of “psychological units” (five to nine) at any moment (Miller,
1956), we have a remarkable capacity for acquiring and retaining visual images.
Therefore, structuring a broad and sustainable knowledge requires explicit
representations (Anderson, 2006). For that reason, we keep the concept map the most
simple as we could, highlighting only the most significant concepts.
Figure 35 illustrates the conceptual map of integration between concepts, from which
we define and establish the relation between elements and architectures.
TOGAF represents an organization from a strategic output to technological
infrastructure, through layered architectures. Therefore, one of the very first
definitions should be about the services delivered, the organization’s output: a “defined
coherent collection of services, accompanied by a contract/set of agreements that specifies the
characteristics, rights, and requirements for their use” (Open Group, 2012).
The product/service provided ought to be aligned with strategic orientations and
integrated with defined goals. In turn, the product/service offered to the
user/costumer influences strategy.
Strategy is responsible for setting the organization’s objectives and defining the
products and services to be delivered to customers. It is also responsible for creating
and sustaining resources (people, knowledge, finance, technology, etc.) needed for
achieving the goals.

91
Figure 35 – Conceptual Map of Integration Between Concepts
An effective service orientation is about providing what users need, with cost
effectiveness. Nevertheless, IT only has value to the business if it delivers the expected
services. User orientation is one of the most important strategic orientations in today’s
organizations (Hochstein et al., 2005). However, customers’ needs and the services
organizations offer do not often match (Mendes & Mira da Silva, 2010), reinforcing
the importance in the alignment of efforts between IT and business (Gama et al.,
2013).
Organizations should link all activities, namely those related to IT, with business
objectives. Therefore, we linked all activities with business objectives from
product/service.
The link between business objectives and IT activities is rarely exposed and,
consequently, the connection between IT and business is also seldom uncovered. Due
to strategy definition, the product/services are shaped according to strategic
requirements since users are only able to understand and pay for what is delivered to
them (the users’ view of the service).
Service Operation
Product/
Service
deliver
support translated in
Applications Information
Technological infrastructure
use
use
support support
provides
provides
translated in
provides
provides
translated in
SLA
Strategy
User/
consumer
Service
Catalogue
influences
establish
define
define
define
delivertranslated
Service Transition
Service Design
Service Strategy
Business
Services
IT Services IT Processes
Business
Processes
Service
Provider
IT Service
Provider
use
use

92
A business service can be described as the focal point of an organization’s activities,
representing the business logic. Business services are shaped supporting business
capabilities through an explicit and defined interface governed by an organization.
There is no attribute list describing a business service. However, a business service
should have the service’s scope in terms of functionality and usage, its price or cost,
and its limitations – the service level agreement (SLA).
The first benefit of a business service layer is the dialogue improvement between
business and IT, namely with infrastructure and operations staff. However, a business
service layer is also another step in business architecture as it applies to the enterprise
business model.
The first challenge is to identify the existing business services (Mendes & Mira da
Silva, 2010; Peyret, 2011a). We may start with the customer-facing business
capabilities and then identify the output of the organization’s candidate business
services: starting with the organization’s output, the products or services delivered to
customers, and establishing a link to the internal business services supporting these
external products/services. The real value will come from collecting the linkages with
underlying services and with people, processes, information, and technology.
From the business services supporting products/services we build the service
catalogue. A service catalogue promotes a better management efficiency through the
provision of defined products/services (Vorisek & Jandos, 2010; Gama et al., 2013). A
service catalogue and well-defined service architecture are prerequisites of effective IT
Service Management.
A service catalogue is a repository of standard services that are available to business
users from internal or external providers of services. The service catalogue is one of
the major deliverables of ITIL, particularly when addressing business services,
becoming the cornerstone for discussions between the business, IT development, and
IT operations. It establishes an intermediary step between business capability concepts
and the low-level and IT-oriented services (Peyret, 2011b).
Usually, IT organizations build their service catalogue bottom-up: they start from
technology services, move to application services, then web services, and finally dub
the combination into a business service. This approach is prone to errors because the
most common behaviour tends to encapsulate the application service using a generic
name that mimics a business service, when in reality the application service is rarely a
business service. Nevertheless, a bottom-up approach after the top-down capability

93
approach is necessary to complete and check the mapping of true business services to
their underlying IT assets (Peyret, 2011a; Rosa et al., 2012; Gama et al., 2013).
We first followed a top-down approach identifying the linkage between concepts along
layers. After that, we verified bottom-up the established relationships, rechecking the
result mapping.
After a preliminary map, a revision is needed, in an iteration process, improving the
map each iteration, with concepts re-repositioning, clarifying all structure and
preparing the final map (Novak & Cañas, 2008)..
From a technical point of view, a business service is translated into basic services, with
elementary functionality (Kieninger et al., 2011) in IT services. An IT service
identifies what is required to support a business service, so it is not essential to know
the users’ needs in detail because they are already translated into product/services. In
other words, we clarify what IT services are needed to provide to the defined business
services. However, it is crucial to determine how these directly affect the performance
of services. The definition of IT services level indicators is done from a service
perspective. IT services are just one level in the decomposition of services.
In order to be clear, we will determine which activities should be developed to support
IT services, namely the activity sequence – the IT processes. The IT processes’
activity sequence is defined and grouped, clarifying our process architecture.
By activity identification, we will determine the provider involved, recognizing task
and roles, and thereafter the actors involved in providing services.
Application architecture is clarified by the identification of applications’ services used
by IT services and also the information CRUD (Created, Read, Updated, and
Deleted), defining its respective information architecture.
Once we have determined information and applications, we can define the
Technological Infrastructure needed to support them, including hardware, network
devices, applications, interfaces between applications, backup devices, printers, etc.
In roles’ identification, the service owner and the process owner take on relevant
importance. The service owner is the one who knows the service from start to the
defined output. The process owner is the responsible for a business process that
supports IT services. The process owner should be identified in the activity
identification.

94
After the concepts’ identification, the next step is the integration of all identified
concepts, defining the correspondent architectures. We used a layered approach to
identify and link architectures and elements.
We continued the work, establishing the relationships as we went along, and stored
the data into our view, providing different views as visualization of the relationships.
Our conceptual map relates and defines other concepts. However, to simplify the
representation, as they are outside this dissertation’ scope, they are not represented in
the map.
For example, an organization that needs to assess the impact of introducing a new
product in its service catalogue may require defining additional business services (or
reusing the existing ones), processes, reallocating actors and roles, changing support
applications, and augmenting the technological infrastructure to support additional
load of these applications. Perhaps this may require a change in the organizational
structure.
As another example, a strategic objective can be defined such as increasing user
satisfaction. Services and products delivered to the users should consider this strategic
goal from new SLA. A product/service as a mail account is delivered from the
business service of mail administration. To deliver this business service we should have
IT services granting support such as Active Directory management, Exchange
management and management of user’s details. All these changes should be
automatically reflected in the respective architectures.
In accordance with TOGAF, an EA should be fully revised on a periodically basis to
incorporate new or changed standards, evaluate new technologies and realign with
changing business priorities. However, the architecture will never be "complete" in the
sense that it should be constantly reviewed and revised, and related efforts realigned.
As the business grows and evolves, so should the architecture governing its systems
and processes. Just like the business itself, the architecture must remain dynamic and
able to change with the demands of the business environment.
Stored in a common repository the services, processes, needed information,
applications, and support infrastructure ensure EA principles, giving special relevance
to the connections between the components and artifacts from the different
architectures. With ITIL processes, the EA repository is an operational support to all
organization’s needs, and to all stakeholders’ activities.
Value will come when different stakeholders with different interests address EA
principles using ITIL processes.

95
One of the problems for the architect designer will be to avoid what is obsolete,
duplicated, incomplete or erroneous. After concluding the design, a major challenge is
to keep information updated.
4.2.7 Summary
TOGAF and ITIL have consistent differences but simultaneously a lot in common. In
both approaches the architecture design starts from organization vision, mission, and
strategy goals, considering resources and capabilities. In ITIL, this start is the basis for
service development, and in TOGAF to the business architecture. Whereas ITIL (in a
logic of service lifecycle development) starts from Service Strategy to Service
Operation through Service Design and Service Transition, in TOGAF from Business
Architecture we develop all the support architectures: Application, Data and
Technology.
Using Table 5 we identified the most relevant concepts and we put them along the
widely accepted layers of EA. As we expected, concepts from different approaches
have much in common.
Since ITIL can be disposed along TOGAF architectures, we may conclude that, at
this level, the integration makes sense. The concepts of the two approaches are similar
and although the integration seems feasible a validation is needed.
The SOA paradigm is applied to both frameworks, and we may conclude that SOA
principles should be used in the integration proposal. Thus, the service definition is
the pivotal point of integration between ITIL and TOGAF. The services are the basis
from which we get the integration between TOGAF and ITIL.
Clarified by the concepts, relationships, and integration between both approaches, we
should be able to define a metamodel from the proposed conceptual map.
Moreover, the integration encompassing the relation between TOGAF and ITIL
requires a shared and single repository with TOGAF principles and policies, and with
ITIL processes.
Furthermore, an architecture model is not just able to provide insight into the current
or future state, but it can also be used to evaluate the transition from the “as is” to the
“to be”, with a strong relationship between developing TOGAF and developing ITIL.
So, a TOGAF transition from a baseline to target architecture should be developed
using ITIL principles.

96
As the integration between TOGAF and ITIL makes sense, now we define the
integration method to validate the integration.
4.3 INTEGRATION METHOD
ITIL was developed with a different focus than TOGAF. To integrate these different
approaches, we should define an ITIL view on TOGAF. Otherwise, ITIL can create
more problems than it solves. For example, a defined process related with a major
incident could imply an emergency change, causing a change in artifacts, and
consequently in the architecture. Without integration between both approaches, it can
lead to outdating the EA even with adequate policies.
Thus, ITIL’s concepts should be distributed along the architectures and linked to
TOGAF following a service-oriented approach, with functionalities made available to
an upper layer as services. Therefore,
if an organization can be represented by TOGAF, with all its layers, concepts
and relationships, and the ITIL concepts and relationships can also be
distributed along layers, then ITIL can be fully merged and integrated with
TOGAF.
This is perfectly aligned with Lankhorst (Lankhorst, 2009) where the general structure
of architectural layers using the same types of relationships and concepts, despite their
natures and granularities, may differ. In this case, connections between layers are
performed explicitly through services (Lankhorst, 2009).
Thus, if one looks at ITIL from this point of view, we realize that by representing and
splitting ITIL across TOGAF layers, we can integrate TOGAF and ITIL by
integrating each one of ITIL concepts in the respective TOGAF layers. Therefore,
if ITIL can be regarded as part of TOGAF, sharing the same domains,
components and relationships, and in the absence of a formal ITIL graphical
language, we can model the ITIL metamodel with TOGAF elements, using
the same language.
In fact, we can only integrate both approaches if they share identical concepts, the
same ontological referential, and, therefore, the same modelling language with a
uniform representation.

97
The entry point to both approaches should be a standard representation of EA,
offering an integrated architectural approach, enabling the description and
visualization of different domains that highlight their relationships and dependencies.
4.3.1 Modelling ITIL with ArchiMate
As we stated before (subsection 2.4.2), ITIL does not have a commonly adopted
modelling language. Most of the times, the description language is natural language,
while processes are depicted as defined sequences of activities by flow charts. The
integration of these processes with the organizational and IT environment is loosely
depicted by graphical diagrams that lack a formal notation and representation.
ITIL is usually depicted just as processes and information architecture. Representing
ITIL along business, application, data and infrastructure architectures is already a
valuable contribution to IT service management. Therefore,
one of our objectives was to provide a formal representation of ITIL that
allows the integration with TOGAF.
As we saw before (subsection 2.2.2), ArchiMate is a graphical language that provides a
formal modelling notation required to address specific concerns related to formal
architecture modelling notation.
ArchiMate was chosen to bridge TOGAF and ITIL as an enabler to their integration.
In fact, like ArchiMate’s own goal, our objective is also ”to provide domain integration
through an architecture language and visualization techniques that picture these domains and their
relations, providing the architect with instruments that support and improve the architecture process”
(Open Group, 2012).
As a result, we developed a solution with ITIL concepts modelled according to
ArchiMate. In effect, by defining ITIL in ArchiMate concepts, an architect can design
an organization with these ITIL building blocks using EA principles and techniques.
In this case, the TOGAF/ITIL integration will be made through ArchiMate’s
definition of principles, concepts, methods and models used as an architecture
language to depict TOGAF.
To start modelling, we mapped ITIL concepts in ArchiMate’s metamodel. From the
five ITIL books, we identified the core concepts (Appendix F – - ITIL Artefacts and
Processes) that belong to each EA layer, as presented in Table 5.

98
We then compared the textual definitions of concepts specified by ITIL to the
concepts defined by ArchiMate, mapping the relationship between both approaches.
The mapping between different approaches is a first step in for developing an
architecture integration from different approaches, and provides a sound formal basis
for modelling in ArchiMate (Meertens et al., 2012).
After that, we colorized each cell of the ArchiMate’s generic metamodel with the
colour code illustrated in Table 6 to facilitate the identification and relationship
between concepts.
ArchiMate’s concepts were then instantiated exhaustively on each of the three layers
(business, application and infrastructure) that were bridged to ITIL concepts.
Table 6 – Cell Colour Code for ArchiMate’s Concept
Information
(Passive)
Behaviour
Structure
(active)
Motivational
Business Layer
Application layer
Infrastructure layer
Table 7 shows how closely ITIL and ArchiMate are related. A detailed description of
each concept is made in Appendix D – - ArchiMate Concepts and Definitions,
Appendix F – - ITIL Artefacts and Processes, and Appendix G – - Concept Mapping
Between ITIL and ArchiMate. We included the ITIL concepts on the left and the
respective ArchiMate concepts on the right.
We then coloured ArchiMate’s concepts (from colours usually used in ArchiMate, and
colour coded in Table 6) for aggrupation purposes, as illustrated in Table 7.
Table 7 –Relationship Between ITIL and ArchiMate Concepts
ITIL Artefacts and Processes
(Appendix F – )
ArchiMate Concepts and Definitions
(Appendix D – )
Activity Business activity
Agreement Contract
Application Service Application service
Application Application collaboration
Application Application component
Application Application function
Application Application interaction
Application Application interface
Objective Business object
Attribute Artifact
Business Customer Stakeholder

99
Business Process Business process
Business Service Business interface
Business Service Business interaction
Business Service Business service
Business Unit Location
Category Meaning
Client Stakeholder
Collaboration Business collaboration
Component Device
Configuration Item (CI) Data object
Configuration Management Database (CMDB) System software
Configuration Management System (CMS) System software
Contract Contract
Customer Stakeholder
System software
Dependency Business collaboration
Event (Business) Event
Function Business function
Infrastructure Service Infrastructure service
IT Infrastructure Device
IT Infrastructure Node
IT Service Infrastructure function
IT Service Infrastructure interface
Job Description) Contract
IT Infrastructure Network
IT Infrastructure Communication path
Objective Concern
Operational Level Agreement (OLA) Contract
Procedure Business activity
Process Business process
Requirement Business activity
Role Business role
Server Device
Service Service
Service Contract Contract
Service Level Agreement (SLA) Contract
Service Owner Business role
Service Portfolio Product
System Device
Underpinning Contract (UC) Contract
User Business actor
Value Value

100
Table 8 – ArchiMate’s Metamodel Concepts Distribution
Value
Business object
Contract
Meaning
Representation
Product
Business service
Business process
Business function
Business interaction
Business activity
(Business) Event
Service
Business interface
Business collaboration
Business role
Business actor
Location
Stakeholder
Driver
Assessment
Data object
Application service
Application
function
Application
interaction
Application
collaboration
Application
component
Goal
Principle
Requirement
Constraint
Artifact
Infrastructure
service
Infrastructure
function
System software
Infrastructure
interface
Node
Communication path
Device
Network
From Table 7 we then distributed the ITIL concepts along the correspondent cells
from ArchiMate’s metamodel (Table 8), obtaining the result shown in Table 9.
Table 9 – ITIL Concepts Distributed by ArchiMate’s Cells
Agreement
Asset
Category
Contract
Operational Level
Agreement (OLA)
Service
Service Contract
Service Level
Agreement (SLA)
Service Portfolio
Underpinning
Contract (UC)
Value
Objective
Job Description
Activity
Business Process
Business Service
Event
Function
Procedure
Process
Requirement
Service
Business Service
Business Unit
Collaboration
Dependency
Role
Service Owner
User
Business
Customer
Client
Customer
Driver
Assessment
Configuration Item
(CI)
Application Application
Objective
Requirement
Critical success
Factor
Specification
Attribute
Configuration
management Database
(CMDB)
Configuration
Management System
(CMS)
Definitive Media
Library (DML)
IT Service
Component
IT Infrastructure
IT Service
Network
Server
System

101
Table 8 summarizes the ArchiMate’s concept distribution metamodel, which serves as
a base to the following classification and distribution of concepts.
Despite the relationship between ITIL and ArchiMate shares many concepts and
semantics, there are some exceptions that will be handled later.
Summarizing, the relationship between concepts was established based on textual
descriptions from ITIL books (Cabinet Office, 2011b, 2011d, 2011f, 2011e, 2011c)
and ArchiMate specification (Open Group, 2012). After the ITIL core concepts were
identified, we mapped them to the ArchiMate’s metamodel.
Mapping ITIL to ArchiMate
In a next step, we exhaustively enumerated the concepts from both approaches and
established a relationship between them. In a first step, we compared the ArchiMate’s
concepts with ITIL concepts, defining a mapping between the two approaches. After
having identified the most suitable matches for ITIL concepts in ArchiMate concepts,
we analysed the relationships between them in order to accurately match ITIL and
ArchiMate.
Once we used ArchiMate as TOGAF language, the concepts’ integration was
established between ArchiMate and ITIL, considering the concepts’ integration
between TOGAF and ITIL as appropriate.
Because the focus is different, it is unlikely that ArchiMate and ITIL share identical
concepts for content structure. In particular, the fact that ArchiMate is a formal
modelling notation, and ITIL could be used within both formal and informal
modelling scenarios, means that the approaches will be divergent.
Due to the lack of a formal ITIL graphical representation, we will evaluate if is
feasible to model ITIL using ArchiMate. ITIL has a semantic definition that we
bridged with ArchiMate’s concepts to show how closely they relate.
ArchiMate was developed to achieve this specification through a non-ambiguous
description of architectural concepts, especially their relationships (Jonkers et al.,
2009).
We evaluated the mapping between ITIL and ArchiMate through ArchiMate’s
metamodels. We started by exhaustively identifying the ITIL and ArchiMate concepts
presented in Table 7.
Taking the ArchiMate’ layers metamodel, we mapped it with ITIL concepts. For
example, in the business layer metamodel (Figure 36) we identified an ArchiMate

102
concept (“Representation”) without any correspondence to ITIL. We marked it with a
red circle in Figure 36.
Figure 36 – ArchiMate’s Business Layer Metamodel (Open Group, 2012)
ArchiMate has a defined symbol notation to each concept along all layers (Open
Group, 2012). The ArchiMate’s symbol notation is presented in Appendix D –
ArchiMate Concepts and Definitions.
We used the same symbols from ArchiMate to represent the ITIL’s concepts (Figure
37, Figure 39, Figure 41, and Figure 43).
Once we do not have a perfect match between ArchiMate and ITIL some concepts
and hence some symbols are repeated.
From the mapped relationship of ITIL concepts to the ArchiMate Business Layer
Metamodel, we identified two ArchiMate concepts (“Business Service” and “Business
Interface”) mapped to a single ITIL concept (“Business Service”) that we marked in
Figure 37 with red circles.

103
Figure 37 – ITIL Concepts Relationship to ArchiMate - Business Layer
We conducted an evaluation similar to the previous one to ArchiMate’s Application
Layer Metamodel (Figure 38). We also used the evaluation method proposed by
(Wand & Weber, 1993) to evaluate the proposal concept mappings from ITIL to
ArchiMate, but that evaluation is presented in the next subsection Ontological
Evaluation.
Figure 38 – ArchiMate’s Application Layer Metamodel (Open Group, 2012)
Value
Contract
Category
Objective
Business
service
Process
Event
Role
Business
service
Job description
Collaboration
Business Unit
Service
Portfolio

104
The ITIL concept “Application” (with a red circle in Figure 39) is mapped to the
ArchiMate concepts “Application Function”, “Application Interface”, “Application
Component”, and “Application Collaboration”.
Figure 39 – ITIL Concepts Relationship to ArchiMate - Application Layer
As illustrated in Figure 40 in the Technology Layer Metamodel, we found the
ArchiMate concept “System Software” without correspondence in ITIL concepts.
Figure 40 – ArchiMate’s Technology Layer Metamodel (Open Group, 2012)
Mapping ITIL to ArchiMate concepts in the Technology Layer (Figure 41), we
identified the ITIL concepts “IT Service” and “IT Infrastructure” related to
ArchiMate concepts two and three. Therefore, in the Technology layer, ArchiMate
seems to be richer in concepts than ITIL.
Conﬁguration Item
Application
Service
Application
Application
Application
Application

105
Figure 41 – ITIL Concepts Relationship to ArchiMate - Technology Layer
Finally, we also conducted an evaluation similar to the previous ones to ArchiMate’s
Motivation Extension Metamodel (Figure 42).
We noticed that we have a perfect match between ITIL and ArchiMate in the
Motivation Extension Metamodel, as illustrated in Figure 42 and Figure 43.
Figure 42 – Motivation Extension Metamodel (Open Group, 2012)
Figure 43 – ITIL Concepts Relationship to ArchiMate - Motivation Layer
Attribute
Infrastructure
Service
IT Service
IT
Infrastructure
Server
IT
Infrastructure
IT Service
IT
Infrastructure
Driver Assessment Objective Requirement
Critical
Success Factor
Speciﬁcation
Client /
Customer

106
We identified that ITIL and ArchiMate share many of the concepts. However, there
are some cases where the match is not perfect leading to misunderstanding or
duplication of classification. Therefore, we needed an ontological evaluation between
the concepts of both approaches, to evaluate the real effect of this unperfected match,
which is presented in the next section Ontological Evaluation.
Ontological Evaluation
An isomorphic mapping is achieved if we have a grammar ontologically clear and
complete. A grammar is ontologically clear if it is neither incomplete nor redundant.
A grammatical construct is complete if it is neither excessive nor overloaded (Fettke &
Loos, 2003; Guizzardi, 2007).
If an isomorphic mapping can be guaranteed, the implication for the human agent
who interprets a model is that his interpretation correlates precisely and uniquely with
an abstraction being represented. We have isomorphism if a defined ontology
representing a domain can be mapped in a language’s metamodel (Guizzardi, 2007).
An ontological model is a set of constructs of an ontology done by a modeller, who
examines the elements of a system for a specific purpose at a given point in time with
a specific language and a defined referential (Fettke & Loos, 2003). Models can be
defined as a mapping or graphical representation of a real world area in a defined
domain (Schuette & Rotthowe, 1998).
In the absence of ITIL constructs neither an ITIL metamodel we can only model
ITIL in an ad hoc way relating textual concepts depending on he author’s
interpretation.
The process of modelling ITIL can be conceived as constructing a mapping of
TOGAF modelling. TOGAF has been improved by the use of ArchiMate as the
architecture modelling language (Jonkers et al., 2009), a grammar that provides a set
of constructs and rules (Wand & Weber, 1993).
Following the work developed by Wand and Weber (Wand & Weber, 1993), we
adopted ITIL the ontological model and ArchiMate as the language grammar.
The ArchiMate grammar must contain constructs that allow modelling, ensuring that
ontological constructs defined by ITIL conditions are fulfilled. In other words,
ArchiMate as a grammar will not produce clear models unless the mapping from ITIL
ontological constructs is straightforward. Therefore, ArchiMate is a grammar
language construct that enables the representation of models, specifying a set of

107
ontological constructs that ITIL must describe. Therefore, any ITIL modelling case
should be able to be represented with ArchiMate.
However, we must guarantee that the ITIL ontological constructs can be described
using ArchiMate grammar. We need to evaluate if the isomorphic mappings between
the ArchiMate grammatical constructs and the ITIL ontological constructs can be
guaranteed.
As we will see ahead, we identified some limitations when mapping ArchiMate and
ITIL. An ITIL metamodel avoid the identified limitations. A metamodel increases
usability by clarifying the mapping between concepts in different a frameworks.
A metamodel of ITIL, as an explicit model of constructs and rules, defining logical
structures and generating semantics, is needed to specify models within the defined
domains of interest.
Another advantage of having a metamodel is that a relation to other metamodels can
be developed, avoiding misunderstandings in concept interpretation, and enabling the
development of generic tools, operating in any ITIL compliant model.
The developed ontological evaluation is conceptually illustrated with the Figure 44.
We used the abstract notion of mapping underlying Wand and Weber’s approach
assessing the ontological completeness (Completeness is achieved when the representation
mapping is total) and the expressive clarity (ontological clarity is the ability of reverse
mapping from the representation, achieved when the interpretation mapping is total
and on-to-one) of ITIL metamodel as ontological construct (Wand & Weber, 1993).
Figure 44 – Ontological Evaluation

108
We recognized that the ITIL has not a high-quality as ontology. Therefore, we
developed an ontological evaluation based on Wand and Weber approach, not an
application thereof.
The following Figure 45 (Fettke & Loos, 2003) illustrates, in respect to both mappings,
how the ontological deficiencies can be distinguished. We compared the mapping of
the ITIL and ArchiMate by identifying four ontological deficiencies from mapping
direction and mapping characteristics (Fettke & Loos, 2003):
• Completeness: can each concept from the ontological construct (ITIL) be
mapped on an element from the grammar (ArchiMate)? The grammar is
complete if the representation mapping is defined in total. Otherwise the
grammar is incomplete.
• Redundancy: are the ontological constructs (ITIL) mapped on exactly one
of the grammatical constructs? The grammar is redundant if the
representation mapping is ambiguous.
• Excess: can each grammatical construct (ArchiMate) be mapped on an
ontological construct (ITIL)? The mapping is excessive if there is one or more
grammatical constructs without a relationship.
• Overload: is every element of the construct grammar (ArchiMate) mapped
to exactly one of ontological concepts (ITIL)? The mapping is overloaded if
one of the grammatical constructs has more than one mapping to ontological
constructs.
Figure 45 – Ontological deficiencies (Fettke & Loos, 2003)

109
Such analysis compares the mapping of the two approaches (ArchiMate and ITIL)
revealing which concepts are missing, confusing or overkill.
We can group the ontological deficiencies in two main areas: completeness and clarity.
Completeness defines the deficiencies as the amount of concepts in ITIL without
representation in ArchiMate. Lack of completeness would be a serious issue for the
mapping between ITIL and ArchiMate. Clarity is the combination of the other
deficiencies: redundancy, excess and overload. Lack in clarity makes the mapping
unidirectional and increases difficulty in the reverse use.
Completeness
ArchiMate is complete (Figure 46) if the mapping of ITIL constructs is total (Wand &
Weber, 1993). Otherwise, ArchiMate grammar has ontological incompleteness (Figure
47) or there is construct deficit. In other words, ArchiMate is ontologically incomplete
since does not provide at least one grammatical construct to every ontological
construct.
Figure 46 – Ontological Completeness,
adapted from (Wand & Weber, 1993)
Figure 47 – Ontological Incompleteness,
adapted from (Wand & Weber, 1993)
All concepts from the ArchiMate grammar can be mapped into ITIL concepts. In
other words, we did not identify any ontological construct from ITIL without
grammatical correspondence in ArchiMate.
Therefore, we can say that our mapping is complete. The ontological model does not
have any construct deficiency and the ArchiMate grammar is richer than the ITIL
ontology.
ITIL ontological construct
ArchiMate grammatical construct
Legend:

110
Ontological incompleteness (or construct deficit) is undesirable, and can be a serious
issue for the mapping. A grammar with ontological incompleteness or construct deficit
is unable to represent all ontological constructs that might interest them.
To face an ontological incompleteness we may need a language extension. If we had
identified ITIL concepts without mapping in the ArchiMate Grammar we should
develop and ArchiMate extension, which was revealed as not needed.
However, in this case, modelling is not a problem since the ArchiMate grammar
construct is richer than the ontology and so ITIL can be represented without
limitations.
Therefore, we can say that our mapping is complete, because there are no ITIL
concepts without ArchiMate correspondent representation. ArchiMate has elements
that are generic enough to accommodate all ITIL concepts, so our mapping reflects
exactly the actual element’s meaning.
The expressive power of ArchiMate as a grammar is how clearly each ontological
construct represents a grammar construct.
Redundancy
Construct redundancy occurs when two or more grammar constructs are used to
represent a single ontological construct, as illustrated in Figure 48.
Figure 48 – Construct Redundancy, adapted from (Wand & Weber, 1993)
Mapping ITIL to ArchiMate concepts (see Figure 41, we have redundancy of the
ITIL concepts “IT Service” and “IT Infrastructure” related to ArchiMate constructs
in the Technology Layer. Also in other in business and application layers (see
respectively Figure 37 and Figure 39), ArchiMate is richer in concepts than ITIL.
Once we have the same ITIL concept related to two or more ArchiMate concepts in
which mapping is ambiguous, we identified Redundancy.
The mapping summary is presented in Table 10 where we identified several redundancy
constructs.

111
As an example in the Business layer, the ontological construct “Business Service” has
representation in several grammatical constructs in our representation model, namely
“Business service”, “Business interaction” and “Business interface”. Thus, the
ArchiMate grammar entity design construct is redundant because it stands for more
than one ontological construct.
Table 10 – Redundancy Concepts
ITIL ArchiMate
Application
Application collaboration
Application component
Application function
Application interaction
Business Service
Business interface
Business interaction
Business service
IT Infrastructure
Device
Node
Network
Communication path
IT Service
Infrastructure function
Infrastructure interface
Objective
Business object
Concern
Goal
Requirement
Business activity
Requirement
Construct redundancy is undesirable because users of the ArchiMate grammar must
bear other knowledge to determine which design construct is being represented by the
ontological construct.
This deficiency can lead to problems if we ever want to do the opposite process: to go
from an ITIL model to ArchiMate and back to ITIL again.
The problem with redundancy is that the “correct” ArchiMate concept has to be
chosen according to context and experience, and although this choice is rather easy
for human architects, it can be a serious problem for automated model
transformations. For example, when architects first sight a relation in a relational
model, it is not clear which relation is represented. In short, construct redundancy
means that the ITIL ontological model loses expressive power because the meaning of
the design constructs is not always clear, manifesting the real world semantics.

112
Excess
Figure 49 illustrates a grammatical construct excess, where some ArchiMate
grammatical constructs does not map interprets some ontological construct.
Using ArchiMate as a grammar to generate a model in the Business layer, we found
(Table 11) that there is no ontological construct to represent the grammatical
construct of “Representation” (Figure 36) or to represent “System Software” in
Technology layer, as illustrated with a red circle in Figure 40.
Figure 49 – Construct Excess, adapted from (Wand & Weber, 1993)
Once some concepts from the ArchiMate grammar cannot be interpreted on
ontological constructs, the grammatical constructs are excessive.
Table 11 – ArchiMate Ontological Incompleteness
ITIL ArchiMate
System software
Representation
Therefore, the grammar is richer than the ITIL ontological model, which was
expected given the wider application of ArchiMate.
This is not a problem since we do not have any ontological constructs without
grammar interpretation. As we stated before, the ArchiMate's grammar constructs are
richer than ITIL ontological constructs and excess it would not be a problem.
Overload
Figure 50 – Construct Overload, adapted from (Wand & Weber, 1993)

113
The construct overload, as illustrated in Figure 50, occurs when one design construct
maps into two or more ontological constructs (Wand & Weber, 1993). ArchiMate has
more than one grammar constructs suitable to represent a single ITIL concept.
As presented in Table 12 we identified several construct overloads.
Table 12 – ITIL Overload Concepts
ITIL ArchiMate
Activity
Business ActivityProcedure
Requirement
Collaboration
Business Collaboration
Dependency
Business Process
Business Process
Process
Role
Business Role
Service Owner
Agreement
Contract
Contract
Operational Level
Agreement (OLA)
Service Contract
Service Level Agreement
(SLA)
Job Description
Underpinning Contract
(UC)
Component
Device
IT Infrastructure
Server
System
Business Customer
StakeholderClient
Customer
Construct overload establishes a case of lack of ontological clarity in what concerns
the design construct. As a result, it may reflect that the expressiveness of the
ArchiMate grammar was undermined. Several consequences may arise; for example,
users remain uncertain about whether two or more ontological constructs truly stand
for the same design construct and face increased difficulty when mapping from design
constructs to ontological constructs.
For example, there are six constructs in the ontological model mapped into a single
grammar construct: “Agreement”, “Contract”, “Operational Level Agreement

114
(OLA)”, “Service Contract”, “Service Level Agreement (SLA), and “Underpinning
Contract (UC)” as we can see in Table 12. Each of these six ontological constructs can
represent the grammatical construct of a “Contract”. As six ontological constructs can
be used to represent a single design construct there is overload.
This overload happens because, as we have mentioned before, since we have to
derive elements from ITIL textual descriptions, it was predictable that several ITIL
concepts would be mapped by a single ArchiMate concept.
One might conceive that all ontological constructs are subtypes of a more general
design construct that could be called “Contract”. For example, on the one hand,
ontological constructs that are SLAs exist relating service provider and service
consumer. On the other hand, OLAs exist relating technical service providers.
Ontological constructs can be distinguished one from others depending on the context
and the environment where they are evoked. A specialized grammar construct could
be mapped in the ITIL ontological model and a property as a choice of production
rule could be specified to define it through a set of alternatives. This new variable
property can then be mapped directly to the grammar construct.
Therefore, a way to diminish this problem is a specialization of ArchiMate to map
ITIL concepts where overload exists.
Identified Limitations
The identified relationship between concepts is based on ITIL textual definitions and
ArchiMate’s metamodels and definitions. While it is often quite straightforward as
both approaches share many concepts and semantics, there are some exceptions:
some concepts have different meanings, others are repeated, and yet others have no
parity.
As for completeness, in terms of concepts, ArchiMate is richer than ITIL.
Therefore, we do not have representation mapping issues. On the other hand, we
verified, as expected, some concepts without ITIL interpretation once the ArchiMate
grammar is excessive.
Excess concepts do not cause problems in the mapping of ArchiMate into ITIL
ontological model. Taking into account all layers’ ArchiMate metamodels (business,
application, and technology), we identified only two concepts: “System software” and
“Representation” without an ITIL matching concept. “System software” is a typical
concept from the Technology Layer, representing something in the software
environment or relating to it as specific types of components and objects deployed in

115
the form of artifacts. “Representation” is the perceptible form of the information
carried by a business object that provides detail.
Attempting to derive an ITIL model from an excessive ArchiMate model may result
in serious problems, as there is nothing in ITIL to map to from these excess
concepts. In such case, one solution could be to eliminate from the ArchiMate model
all the excess concepts (which obviously leads to information loss).
We may follow two strategies to try to overcome the problem. First, we may invoke
another ontological construct to stand for the unrepresented design construct. For
example, since ITIL has no construct for representing “System software”, the
construct “IT service” can stand for both “System software” and “IT service”.
However, using one ontological construct to represent multiple design constructs
creates new problems once the ontological construct becomes semantically redundant.
Second, we may develop the ITIL ontological model to represent the design
constructs where there is deficit. This implies an extension of the ITIL ontological
model, which seems to be the most appropriate approach. However, this means the
creation of new concepts without ITIL correspondence.
On the other hand, in some situations, ArchiMate has more than one suitable concept
to represent a single ITIL concept. This situation appears in the literature as construct
redundancy. More precisely, this situation occurs in the case of the “Application”,
“Business Service”, “IT Infrastructure”, “IT Service”, “Objective”, “Requirement”,
“Role”, and “Service”.
A construct redundancy, even reflecting abstraction, is likely to be problematic.
When the construct redundancy occurs, a new ontological construct could be
introduced into the ITIL ontological model to eliminate redundancy. However, as
stated before, this may lead to create ontological without correspondence in ITIL.
Using (Wand & Weber, 1993) model to identify the nature and extend of construct
redundancy in a grammar allow us to evaluate it more carefully. The redundancy
problem can be avoided defining modelling rules to be followed in ITIL modelling.
Only defining a clear semantic we can avoid the arbitrariness when representing
ontological constructs.
The problem with redundancy is that the “correct” ArchiMate construct has to be
chosen according to context and experience, and although this choice is rather easy
for human architects, it can be a serious problem for automated model
transformations.

116
Concept redundancy means that we have to choose one of several options when
mapping an ITIL model into an ArchiMate model. For pure visualization, an
arbitrary concept can be chosen from the mapping options, preferably in such a
manner that it represents only one ITIL concept. For (formal) development of an EA,
this does not always suffice.
Redundancy does not represent a problem in terms of ITIL representation.
However, in terms of modelling accuracy may signify a problematic issue.
Therefore, we can create new ITIL ontological constructs that correspond to
grammar constructs, which are not covered by the initial set of constructs defined in
the ITIL ontological model. This can be made through ITIL specialization, or by
creating an ITIL extension with the aforementioned problems. Therefore, a better
solution is to create clear modelling rules to be followed in ITIL modelling. An ITIL
metamodel will diminish the redundancy problem.
We also identified overload that lead to issues with interpretation mapping from
ArchiMate to ITIL (or for reverse engineering). A choice would have to be made,
based on the context. Overload may also suggest that ArchiMate is not complete
from an ITIL perspective, which is not the case. To avoid overload, while modelling,
we should specialize ArchiMate’s language constructs, which is totally aligned with
ArchiMate specification “Specialization is a simple and powerful way to define new concepts
based on the existing ones” (Open Group, 2012).
We must ensure that the ontological construct is exhaustive and has a corresponding
design construct in the overloaded concepts. That is, all we might want to model has
an instance of one of these specialized types. Otherwise, the meaning of the
ontological construct and the meaning of the design construct could not be the same,
and the later could not have interpretation mapping in the former. Furthermore, if we
do not specialize overloaded constructs some arbitrariness may occur in how we select
the mapped constructs in the ITIL ontological model.
In short, construct overload can be avoided by using specializing constructs in the
ArchiMate grammar relatively to the ontological constructs. Once construct
overload has been identified, it is important to check that all instances in the domain
of the ontological construct are covered by one of the ArchiMate grammatical subtype
constructs.

117
Summary
We identified some ontological deficiencies in clarity area. Some concepts did not
match, which makes difficult to represent and interpret mapping from ArchiMate to
ITIL and vice-versa. Thus, we should define a more accurate mapping, avoiding
misunderstandings and misalignments in concepts by eliminating or diminishing
ontological deficiencies.
Therefore, we conclude that semantic rules should be defined into the ITIL
ontological model to modelling ITIL in the design constructs, overcome redundancy
where deficit exists. This means that we must define a mapping between ITIL
ontological constructs to correspond to defined design constructs that are not covered
by the initial set of constructs defined in the ontological model. This semantic will
define modelling rules representing ITIL in the grammar language. An ITIL
metamodel will define the relationship among ontological constructs.
On the other hand, where ontological constructs are well-defined and we cannot find
ArchiMate correspondence, we should specialize ArchiMate’s constructs avoiding the
overload design construct.
An important structural source of information should be present at ontological
construct as a metamodel relating the different concepts. A metamodel is needed as a
consistent representation of all relevant concepts, both from different layers and views.
The metamodel entities show the purpose of each construct and the key relationships
that support model traceability.
In addition, is needed a metamodel allowing the use of the appropriate modelling tool
(Braun & Winter, 2005). With ArchiMate language we can define the end-to-end
traceability in this metamodel and create several viewpoints such as the layered
viewpoints, which shows several layers and aspects of a model in a single diagram.
4.3.2 ITIL Metamodel
Despite the advantages in the adoption of ITIL’s best practices, some problems have
been identified (Shen et al., 2010):
• The complexity of ITIL concepts causing different interpretations;
• Different tools and methodologies leading to different approaches to the same
problems;
• Even with universal understanding of the concepts, the exchange of process
models in different process model languages still remains a challenge.

118
Therefore, in order to adopt and improve the IT service management lifecycle, many
organizations follow ITIL’s best practices, without a reference model.
We identified some limitations when mapping ArchiMate and ITIL. This happens
fundamentally for two reasons. First, we derive ITIL’s concepts from textual
descriptions of ITIL concepts. Second, because ITIL has a different focus than
TOGAF, concepts are not very specific on layer’s descriptions. The identified
limitations were translated in ontological deficiencies.
With a metamodel, we avoid the identified limitations of mapping ITIL and
ArchiMate.
Besides all published work and books about ITIL, a metamodel expressing the core
concepts, the relation between them, their constraints and limitations is still missing,
especially with academic support. A metamodel increases usability by clarifying the
relationship between concepts in a framework's adoption.
A metamodel of ITIL, as an explicit model of constructs and rules, defining logical
structures and generating semantics, is needed to specify models within the defined
domains of interest. Due to ITIL’s wide acceptance, the most important contribution
of an ITIL metamodel would be the convergence of approaches and applications of
leading vendors and motion towards ITIL compliant solutions.
Another advantage of having a metamodel is that a relation to other metamodels can
be developed, avoiding concept interpretation misunderstandings and enabling the
development of generic tools, operating in any ITIL compliant model.
Facing the identified limitations of mapping ArchiMate and ITIL, we propose an
ITIL metamodel, which does not exist, thus providing an academic contribution in
this area. The proposed metamodel addresses the identified problems, namely:
• Describing the core concepts of ITIL so as to be used by both approaches;
• Represent the ontological constructs, eliminating overload where deficit exists;
• Allowing the integration, exchange, sharing and reutilization of models based
on the proposed metamodel;
• The use of concrete syntaxes, following the defined principles supported by the
metamodel;
• Following the metamodel using different modelling languages.
Following the OMG definition, where a model is an instance of a metamodel (OMG,
2003b), an ITIL metamodel will be a model to shape ITIL, clarifying the concepts
description and relation among them.

119
The relation between a model and its metamodel is similar to the relation between a
book and the language in which it is written, defined by its grammar – a metamodel is
the basis of a model.
To the best of our knowledge, there is no universally accepted ITIL metamodel that
constitutes an ontological reference. This ITIL metamodel should be the basis for
graphical representation, allowing the modelling development.
We started our proposed ITIL metamodel considering that metamodels represent
logical structures and fundamental semantics for the analysis, adaptation, comparison
and integration of frameworks such as ITIL (Neto & Neto, 2011).
Ontological metamodelling is particularly important for model driven development,
especially because it serves as the basis for “framework-based” modelling (Atkinson &
Kühne, 2003). Therefore, a semantic language is provided by an ontology, clarifying
what a metamodel instance needs in order to satisfy a model.
Following some previous published work (Atkinson & Kühne, 2003; Strahonja, 2009;
Shen et al., 2010; Neto & Neto, 2011; Ostrowski et al., 2012) we defined two separate
orthogonal dimensions of metamodelling: one dimension concerned with language
definition and the other with ontological representation.
Linguistic concepts and ontological models are complementary and equally needed in
metamodelling. Both forms occur simultaneously, and serve to precisely locate a
model element with the language-ontology space. A metamodel based on an
ontological model, mapping linguistic concepts, allows the development of a semantic
ITIL metamodel.
Once we cannot define ITIL as a formal ontology, we must define a description of
entities through the definition of properties, relationships, and constraints. Thus,
providing a global understanding; and simultaneously defining rules to modelling
purpose.
Notwithstanding, as a semantic model, the relation to reality and the interrelation of
concepts are true if they obey to a mathematical structure for all axioms and
derivation rules of the structure (Schuette & Rotthowe, 1998).
Firstly, we identified the core concepts from the ITIL glossary (Appendix F – - ITIL
Artefacts and Processes) and reduced the concepts to the fundamental ones, with
representation needs that should be part of the metamodel. To do this, we followed
the above mentioned ontology engineering process (Ostrowski et al., 2012) and

120
analysed the ITIL domain, clarifying abstract concepts from ITIL’s books
specifications.
Secondly, we linguistically defined all concepts for an ontological common
understanding, adding a mathematic representation to concepts and relationships.
This clarification provided design rules at the modelling process decreasing the
concept’s abstraction but allowing the fundamental distinction of the concepts relation
and interoperability in modelling.
Linked to the step above, we identified all relationship connectors between concepts.
The next step defined the notation, clarifying the ontological metamodel and, thus,
the metamodel.
Concepts Identification and Characterization
As stated before, we used the ontology-engineering methodology (Ostrowski et al.,
2012) to identify concepts and relationships from ITIL’s five books. The ontology
engineering process (illustrated in Figure 2) is done through the collaboration of
practitioners from the field and literature review.
Following the ontology engineering process, and reflecting on the structure of
concepts, we started by defining the domain, the terms, their properties, and purposes.
After we identified the terms, we created the concepts and determined their relations
to other concepts.
Following this first step, we created and generated (construct) concepts providing the
ontological vocabulary and symbols used to define a domain’s problems and solutions
(Hevner et al., 2004; Vaishnavi & Kuechler, 2007). After this process, we modelled
their relationships representing situations as problems and solution statements (March
& Smith, 1995).
Since the subjectivity of modelling cannot be eliminated but only managed, a demand
for rules that have to be carried out in the modelling process should be derived. Only
through the formulation of modelling conventions does the design process become
comprehensible, and the integration of different models into a model is simplified.
This way not only can the modelling process be shortened, but the danger of a
defective integration can also be reduced.
Therefore, before developing the metamodel, we defined a basis for the development
of a language (metamodelling language capability), identifying the core concepts by
description and, especially, by definition in order to outline the abstract syntax of a

121
modelling language. From these concepts we define a mathematic representation to
concepts and relationships.
Table 13 presents the language definition that provides an ontological clarification
through the definition of linguistic concepts.
Table 13 – ITIL Metamodel Core Concepts
Concept Description Definition
Service
Portfolio
The service portfolio S represents the
current complete set of services. S is a key
element and it is used to manage the entire
lifecycle of each service si ∈ S. It includes
three categories: (i) Service Pipeline P with
P ⊂ S (proposed or in development); (ii)
Service Catalogue C with C ⊂ S (live or
available for deployment); and (iii) Retired
Services R with R ⊂ S.
S = {s1, s2, . . . , sn}
! = ! ∪ ! ∪ !
∃ si ∈ S : si ∈ P ∨
si ∈ C ∨ si ∈ R
Business
Service
A Business Service si definition covers from
an ITIL book to an IT service. Both cases
can share the same metamodel despite
having different levels. A Business Service
si is a vector performed by a Role ρ as
defined as a Contract ci and in function of
a Process Π
si ∈ C
si = (ρ,f(Π), ci)
Process
A Process πi from the set of Processes Π is a
structured set of Activities Δ designed to
conduct a Service si under a defined Role ρ
and triggered by an Event εi and delivering
an Event εo.
πi ∈ !
πi = (f(Δ), εi
, εo
, !)
Role
A Role ρ from a set of roles R is defined as
a specific behaviour of a stakeholder σ (a
business actor) participating in a particular
context and defining a set of responsibilities
in a Process πi or in a Service si
!I = f(σi)
∀x ∈ R ∃ σ ∈ Σ:
! ! ∈ R
Activity
A set of actions Aij designed to achieve a
particular result in a Process πi. An Activity
Δ can have one or “n” actions aij
Δ =
n
i = 1
αij
1 ≤ Δ! ≤ n

122
Action
An atom activity αij with defined procedure
from a set Αij of possible actions. Actions
can be performed by a Stakeholder or
automatically by an Application Service asi
Αi = {αi1, αi2,…αin}
αi1= f(asi)
Stakeholder
A stakeholder σ represents a person with a
defined interest in a set of Stakeholders Σ
with a defined Role ρ at a given moment t.
σt = (σ1t, σ2t,…, σnt)
∈ Σt
∀x: σ(x) → !(x)
Contract
A compromise ci between two or more
parties.
Ci ∈ {OLA, SLA,
Agreement, UC}
Event
A set ξ of events ei triggering a Process Π
as input of a Process or eo produced as
output, referring any change of state or
anything that happens (internally or
externally).
Ξ = {ei1,ei2,…ein} ⋃
{eo1,eo2,…eon}
∀ei,o : ei,o ∈ ξ
Application
An externally visible unit of software
functionality asi, provided by one or more
components, exposed through well-defined
interfaces, and required by an Action αi.
Each Application may be part of more
than one IT Service. An Application runs
on one or more Infrastructure Service f(νij).
Asi = f(afi)
asi ∈ ASi
IT Service
Externally visible unit of IT Infrastructure
functionality νij, from the overall
organization’s technologic infrastructure
Nij provided by one or more Infrastructure
Function, exposed as service to the
Application Function.
N!" =! νij
!
!,!
νij ∈ Ni
IT
Infrastructure
A Node νij from a set Ni of computational
resources provides f(νij) services to the
Infrastructure Service. A Node νij is
interconnected by communication paths γij
conducted by a network Ψij
Ni = {νi1, νi2,… νin}
∀ν ∈ N ∃ γ ∈ Ψ
The language definition (Table 13) clarifies concepts and provides an ontological
clarification through the definition of linguistic concepts.
We may have concepts’ extensions that allow multilevel instantiations establishing its
own kind of ontological metalevel definitions. However, other levels metamodel’s
definitions should be kept on the same detail level, keeping the metamodel integrity.

123
Therefore, this proposal metamodel allows a hierarchy of metamodel levels where
each level is “an instance” of the level above.
The top level defines the ITIL metamodel, also defining the core concepts and
respective relationships. The multilevel metamodel specifies the existence of
orthogonal metadimensions and the relationship between model elements. In the
following subsection we present a graphical representation of the metamodel.
Metamodel Representation
To start ontological metamodelling, we needed to map ITIL concepts in the
language’s metamodel.
The proposed ITIL metamodel formalizes expressiveness through the definition of
concepts and corresponding visual representation. The ITIL metamodel proposed in
this work is based on the structure illustrated in Figure 51, which relies on concepts
presented in Table 13.
Figure 51 – Proposal ITIL Metamodel
“Processes” deliver and manage “Services”, which have a defined and appropriate
“Contract” typically SLA, OLA, or UC. The dependencies between “Service”,
“Contract” and “Stakeholder” is perfectly aligned with the ontology for IT services as
defined by Freitas et al. (Freitas, Correia, & Abreu, 2008).
Service
Process Role
Activity
Action
StakeholderEvent
Contract
realised by
realises
supported by
supportstriggers
triggered by
Application Infrastructure
Uses
Accessed by
Supported by
Supports
Data
Accesses
Used by
Record
realised by
realises
Associated
with
Deﬁnes
Deﬁned by
supported by
supports
Associated
with
created by
creates
uses
used by

124
“Processes” fulfils a set of “Activities”, which can be performed accessing and using
information “Records” through a set of “Actions” as the atomic part of “Activities”.
“Application Service” that are the interface of a piece of software implemented by
“Applications” that implements “Actions”.
The “Application” uses the “Infrastructure” interface that encapsulates an
infrastructure function provided by the “IT Infrastructure”.
Further details with the most relevant concepts related to the ITIL metamodel are
included in Table 13 and illustrated in Figure 51.
From the proposed ITIL metamodelling language capability in Table 13, we
modelled ITIL main concepts and relationships in the language’s metamodel
integrating ITIL and ArchiMate concepts.
To illustrate the usability of our proposed (Figure 52), we modelled the ITIL
metamodel using the ArchiMate’s language (Open Group, 2012). The use of
ArchiMate language seems obvious since ArchiMate was the basis of our development
is the integration between TOGAF and ITIL, but we may represent the metamodel in
any another notation. This generalization makes it possible to model in different
languages, and the integration and reuse of models.
The relations among concepts are from eight types (as follows) presented in Figure 52:
• Triggering - describes a causal relation between concepts in a sequence flow;
• Association - models a relationship between concepts defining a relationship
where concept’s characteristics are complementary;
• Realization - links a logical entity with a more concrete entity that applies it;
• Access - indicates that a concept "does something" with a data concept;
• Specialization - models a concept that is specialized in another concept;
• Composition - indicates that a concept consists of a number of other
concepts, which can be part of only one composition;
• Used by - models the use of services that a role or concept offers used by
other concepts, or interactions and the access to interfaces by roles;
• Aggregation - indicates that a concept groups a number of other concepts,
which can be part of more than one aggregation.

125
Figure 52 – ITIL Metamodel Modelled using ArchiMate
The usability of our proposed ITIL metamodel is also demonstrated by its use in the
modelling of several ITIL models (Vicente, Gama, & Mira da Silva, 2013b, 2013a)
and using our metamodel with the TOGAF language ArchiMate, as presented in the
subsection 4.3.3 - Integration Viewpoints.
ITIL Specialization
Most of ITIL’s concepts can be mapped to the ArchiMate concepts, some have no
direct relation, where others fail the ontological evaluation. The mapping analysis did
not give a total match between approaches.
In this context, we may need to identify new concepts, proposing an ArchiMate
extension to ITIL representation from the ITIL metamodel. After that, ArchiMate
should reference the generic metamodel to ITIL. The ArchiMate metamodel should
in turn be traceable back to the ITIL metamodel. This means that any ITIL concept
can always be mapped to ArchiMate concepts and the reverse is also possible.
1. Triggering
2. Association
3. Realization
4. Access
5. Specialization
6. Composition
7. Used by
8. Aggregation
Connectors:

126
The creation of a new extension is perfectly acceptable under ArchiMate’s
specification (Open Group, 2012). In fact, the core aspects of the language are mainly
operational, containing only the concepts and relationships that are necessary for
general architecture modelling. Since numerous other aspects are not covered with
the ArchiMate framework, some of which cross several conceptual domains, extension
creation is expected (Open Group, 2012).
Therefore, specific extensions can be developed to add new concepts, relationships,
and attributes while complying with the design restrictions, making ArchiMate's
artifacts explicitly as small as possible (Open Group, 2012).
In fact, through extension mechanisms, the language facilitates the development of
specialized or domain-specific purposes as, for example, to capture the specificity of a
defined domain such as ITIL. However, as stated before, we do not feel need to create
an ArchiMate extension.
The specialization mechanism is a simple and powerful way for the definition of new
concepts based on existing ones. Specialized concepts inherit the properties of their
“parent” concepts, but may apply additional restrictions with respect to their use
(Open Group, 2012). The new specialized concepts has a more specific meaning than
the existing one, and inherits all the properties of its “parent”.
Specialization of concepts provides extra flexibility, as it allows organizations or
individual users to customize the language to their own preferences and needs, while
the underlying precise definition of the concepts is conserved. This also implies that
analysis and visualization techniques developed for the ArchiMate language still apply
when the specialized concepts are used (Open Group, 2012).
Therefore, a technique is needed for mapping ArchiMate to the ITIL specialization.
New concepts should relate to the existing ArchiMate concepts, ensuring consistency
with the current language concepts. An ontological analysis of the new concepts
ensures their semantic interoperability with ArchiMate concepts. We followed the
following principles to the specialized concepts (Iacob, Quartel, & Jonkers, 2012):
• Reuse of concepts and ideas from existing evaluation techniques and models;
• Ensure the alignment with the current ArchiMate metamodel specification.
• Keep the number of new concepts to a minimum;
• Make sure existing ArchiMate concepts and relationships are reused;
• Ensure they are easy to learn, understand and use; and
• Easily accommodate model-based evaluation techniques.

127
Specialization allows to create new design constructs that were introduced into the
ITIL grammar that are not covered by the initial set of constructs defined in the ITIL
ontology, eliminating overload. On the other hand, redundancy is avoided using
modelling rules relative to the ontological constructs.
Through specialization we avoid the creation of a new ITIL extension to ArchiMate.
Figures below present the concept’s specialization we needed to a complete ITIL
modelling and mapping to ArchiMate.
To overcome the identified ontologies deficiencies we propose the following
specialization concepts to ArchiMate modelling (Figure 53 to Figure 52).
Figure 53 – Business Activity Specialization
Figure 54 – Business Collaboration
Specialization
Figure 55 – Business Process
Specialization Figure 56 – Device Specialization
Figure 57 – Contract Specialization
Figure 58 – Business Role
Specialization
Figure 59 – Stakeholder Specialization

128
4.3.3 Integration Viewpoints
Architecture models are created with different motivation and integrate diverse
descriptions. Modelling is a process by which the architect, along with the
stakeholders, makes a model and structure, to one or more viewpoints serving a
defined purpose.
Views give information about architecture areas defining part of an architecture
description that addresses a set of related concerns and is addressed to a set of
stakeholders. A view is specified by means of a viewpoint, which prescribes the
concepts, models, analysis techniques, and visualizations that are provided by the view
(Open Group, 2012).
Viewpoints are a means to focus on particular aspects of the architecture and
are designed for communicating certain aspects of it, using a view established
by a purposes and audience.
A viewpoint-oriented approach to modelling defines abstractions on the set of models
representing a view, each aimed at a particular type of stakeholder and addressing a
particular set of concerns, enabling the communication (Lankhorst, 2009; IEEE
Computer Society, 2011). In this case, a view is what we see, and a viewpoint is where
we are looking from (Open Group, 2012).
The Open Group defines a set of viewpoints with ArchiMate, providing a framework
for the selection of a relevant subset of concepts and their relationships, representing
part of an architecture expressed in different diagrams, relating the interest of each
stakeholder (Open Group, 2012).
Viewpoints classification is based on two dimensions: purpose and content. Purpose
may be of type Designing, Deciding or Informing, while Content clarifies the
abstraction level of Details, Coherence or Overview.
Figure 60 presents the dimensions of purpose and abstraction level, together with
examples of typical stakeholders that are addressed by these viewpoints. The top half
of this figure shows the purpose dimension, while the bottom half shows the level of
abstraction or detail (Open Group, 2012).
An architecture description shall identify the system stakeholders and the concerns
considered fundamental to the architecture of the system-of-interest (IEEE Computer
Society, 2011). Likewise, we also need to focus and communicate particular aspects of
the architecture.

129
Figure 60 – Classification of EA Viewpoints (Open Group, 2012)
TOGAF, ArchiMate and ITIL have a similar layered structure. This correspondence
allows a mapping between concepts and therefore between viewpoints. Creating ITIL
viewpoints using ArchiMate’s purposes and abstraction levels appears to be
appropriate.
In this section we propose a set of viewpoints to represent ITIL and organizations that
use ITIL, according to our metamodel elements, concepts and concerns, using the
ArchiMate’s purposes and abstraction levels.
We present some of the obvious ITIL viewpoints, but others could be produced to
represent other interests or concerns.
The main purpose of these viewpoints is to model, describe and communicate to the
organization stakeholders the ITIL elements and relationships, according to how they
are advised on ITIL best practices.
Full models shall represent the whole ITIL processes, while partial models represent
the parts of ITIL that each organization has implemented.
We divide our viewpoints in two sets:
• The viewpoints that show how ITIL concepts are modelled, for which we
propose the ITIL Book Viewpoint, the ITIL Process Viewpoint, and the ITIL
Process Detail Viewpoint.
• The viewpoints that assign ITIL concepts to instances in the organization.
These viewpoints are the ITIL Strategy Viewpoint, the ITIL Service
Catalogue Viewpoint, the ITIL Service Provider Viewpoint, the ITIL Service
Viewpoint, and the ITIL Compliance Viewpoint.

130
Across the viewpoints we used the ArchiMate’s usual colour scheme (green for
technology layer concepts, yellow for business layer concepts and blue for application
layer concepts).
ITIL Book Viewpoint
This viewpoint represents each ITIL book as a set of ITIL processes that provide
services supported by the processes.
Table 14 – ITIL Book Viewpoint
ITIL Book Viewpoint
Stakeholders Architect, Designer, User, Customer
Concerns Understanding the operation and
dependencies of ITIL processes
Purpose Designing, Deciding, Informing
Abstraction Level Overview
Layer Business, Application, Technology
Aspects Structure, Behaviour, Information
Concepts and Relationships Figure 61 illustrates the core concepts and relationships
of the ITIL Book Viewpoint.
The main purpose of this viewpoint is to communicate ITIL and help architects and
business process designers to understand the operation and dependencies of ITIL
books and processes, by providing an ITIL overview over all the organization’s layers.
Figure 61 – Concepts and Relationships of ITIL – Book Viewpoint

131
Example of Concepts and Relationships
Figure 62 illustrates the partial representation of the Service Transition book with part
of Knowledge Management process.
Figure 62 – Example of ITIL – Book Viewpoint
ITIL Process Viewpoint
This viewpoint shows how a process is conducted focusing on the relationships
between an ITIL process and the concepts across the several layers of the
organization. The ITIL Process Viewpoint purpose is mainly to understand each ITIL
process through a holistic vision of how it functions and how it relates to its
environment.
Table 15 – ITIL Process Viewpoint
ITIL Process Viewpoint
Stakeholders Architect, Designer, Manager
Concerns Understanding the detail and
operation of ITIL processes
Purpose Designing, Deciding
Abstraction Level Coherence

132
Concepts and Relationships
Each process always has a trigger event and a manager. A process is a set of sub-
processes, activities and functions that uses application services.
Figure 63 – Concepts and Relationships of ITIL – Process Viewpoint
Figure 64 illustrates an example (the Problem Management) process and the
relationship with other processes.
Figure 64 – Example of ITIL Process Viewpoint

133
ITIL Process Detail Viewpoint
The ITIL Process Detail Viewpoint focuses on the individual activities of each ITIL
process and how they cooperate and use the ITIL elements outside the process. In this
viewpoint, it is possible to see how the process internally operates to achieve its
purposes. This viewpoint provides enough detail to help process owners and architects
to design the organization processes according to ITIL.
Table 16 – ITIL Process Detail Viewpoint
ITIL Process Detail Viewpoint
Stakeholders Process Designer, Architect
Concerns Defining ITIL processes detail
Purpose Designing
Abstraction Level Detail
Layer Business
Aspects Behaviour
The ITIL Process Detail Viewpoint exposes the process’s activities and its respective
relationship in more detail.
Figure 65 – Concepts and Relationships of ITIL – Process Detail Viewpoint
The example illustrated in Figure 66 shows the functions associated with the Incident
Management process.

134
Figure 66 – Example of ITIL – Process Detail Viewpoint
ITIL Strategy Viewpoint
The ITIL Strategy Viewpoint shows how the strategy influences the service portfolio
since strategy affects design choices keeping concerns in alignment, and different
strategic objectives require different approaches. Likewise, alignment is a key driver in
strategy viewpoint. Strategy takes shape through services and is influenced by users. A
service portfolio ensures a defined strategy while business processes guarantee the
alignment between strategy and customer’s needs.
Table 17 – ITIL Strategy Viewpoint
ITIL Strategy Viewpoint
Stakeholders Process Designer, Architect, Manager,
Owner
Concerns Strategy, Service Portfolio, Service
Catalogue
Purpose Designing, Deciding
Abstraction Level Overview
Layer Business
Aspects Behaviour, Information
The strategy orientation is defined and clarified by the products an organization wants
to deliver. The strategy defines the service level that enables to achieve the defined
goals.

135
Figure 67 – Concepts and Relationships of ITIL – Strategy Viewpoint
Figure 68 illustrates the increase of the number of users as the fulfilment of a new
strategic objective. The goal to achieve this driver is the reduction in SLA’s time and
the definition of new SLAs.
Figure 68 – Example of ITIL – Strategy Viewpoint
ITIL Service Catalogue Viewpoint
The Service Catalogue viewpoint focuses on an overview of all the IT services that an
organization provides. It also shows the IT elements that support (or expose) those
services. It is useful to communicate the organization’s IT service architecture and to
help service providers to model several of its client organizations, representing which
are the services of each client, the Service Level Agreements, and the IT applications
and infrastructure that support those services.

136
Table 18 – ITIL Service Catalogue Viewpoint
ITIL Service Catalogue Viewpoint
Owner, Customer, Client
Concerns Service Portfolio, SLA
Purpose Designing, Informing, Deciding
Layer Business
Aspects Behaviour, Structure, Information
Following a service orientation, a service catalogue is the basis to all development
work. From the strategy we define our products and respective services. To achieve
the defined level of service, we need support processes.
Figure 69 – Concepts and Relationships of ITIL – Service Catalogue Viewpoint
The example depicted in Figure 70 illustrates a product defined as User Support that,
from the Service Portfolio, has the service Desktop Management in the Service
Catalogue. This service Desktop Management has the technical service Material
Service that is supported by the process Material Provision, enrolled by the Stock
Manager, and supported by the system Stock Management Software.

137
Figure 70 – Example of ITIL – Service Catalogue Viewpoint
ITIL Service Provider Viewpoint
The ITIL Service Provider Viewpoint focuses on modelling and representing an IT
Service Provider. This viewpoint allows modelling the services provided according to
the service provider’s architecture and also the customer’s own architecture, making
clear the locations where the IT elements are deployed and how both organizations
communicate.
Table 19 – ITIL Service Provider Viewpoint
ITIL Service Provider Viewpoint
Owner
Concerns Service Providers and Consumers
Purpose Designing, Informing
Layer Business
Aspects Structure, Behaviour
An IT Service Provider has a defined location, an actor and a role. The use of this
viewpoint is related to the identification, such as for contact purpose.

138
Figure 71 – Concepts and Relationships of ITIL – Service Provider Viewpoint
Figure 72 illustrated the IT Service Provider of Service Desk. Two sites (Olivais and
Restelo) supports the. Service Desk function. Despite the same team supporting the
same role, physically these two sites are distinct and with different people assigned.
Figure 72 – Example of ITIL – Service Provider Viewpoint
ITIL Service Viewpoint
This viewpoint shows how services are conducted along layers of an EA in a single
diagram. The layers are the result of the use of the entire set of concepts and
relationships that belong to the model. Thus, the ITIL Service Viewpoint depicts the
bridge between service, business process, application, and technology views, in how a
service is made concrete.
This viewpoint is closely related to ArchiMate’s Service Realization Viewpoint.
However, in ArchiMate the service is only realized to the application layer bridging
the business service and the business process.

139
Table 20 – ITIL Service Viewpoint
ITIL Service Viewpoint
Owner
Concerns Defining a consistent viewpoint of a
service’s concretization along all layers
and its respective concepts’
relationships. Showing the impact of
change
Abstraction Level Coherence
Figure 73 – Concepts and Relationships of ITIL – Service Viewpoint
The ITIL Service Viewpoint shows how a service is realized. Each service should have
an associated contract, typically a SLA. Each service is concretized by a process or
function, which is performed by a defined role. The process is performed using data
and application, accessed through the respective application service. The applications
and data are supported by the technologic infrastructure.
Thus, this Viewpoint is the bridge between the business, application and
infrastructure layers, providing an overall overview of a service.

140
In this example, Figure 74 shows how the service “Web Portal” is deployed along all
layers. The process “Portal Management” keeps the function (Service Desk) and a
sub-process (Change Portal). Both, process and function are supported by two
applications, respectively, SharePoint (BackOffice) and EasyVista (Service Desk
Service) accessed by the respective applications services. Different servers support the
applications.
This viewpoint allows understanding the service’s implication in changing any of the
components that supports the service.
Figure 74 – Example of ITIL – Service Viewpoint
ITIL Compliance Viewpoint
The ITIL Compliance Viewpoint focuses on assigning the ITIL concepts and
relationships to the actual architectural elements that represent them.
An ITIL Compliance Viewpoint can be an instance of any of the other ITIL views,
where we add the actual IT applications, business roles, and infrastructure elements
that the organization uses to adhere to ITIL best practices.

141
Table 21 – ITIL Compliance Viewpoint
ITIL Compliance Viewpoint
Stakeholders Process Designer, Architect, Customer,
User
Concerns Compliance assessment between
organization’s artefacts and processes
and ITIL
Abstraction Level Details, Coherence
This view is mainly used to check for compliance, to see how an organization’s IT
service architecture is compliant with the ITIL best practices framework. Comparing
the ITIL processes and functions with organization real state, allows to identify lacks
and to check the improvements needed.
Figure 75 – Concepts and Relationships of ITIL – Compliance Viewpoint
In this example we modelled the ITIL's Service Desk function in how it should be
deployed. Applying the ITIL Compliance Viewpoint we can evaluate our process or
function. In the example illustrated with Figure 76 we can assess that the Service Desk
function was well established once the mapping is perfect.

142
Figure 76 – Example of ITIL – Compliance Viewpoint
4.3.4 Summary of Integration Method
In this section was presented the model to the integration between ArchiMate and
ITIL. We started by identify the ITIL and ArchiMate concepts. We mapped the ITIL
concepts to the ArchiMate metamodels identifying the deficiencies, once we do not
have a perfect match between ITIL and ArchiMate concepts.
With ArchiMate as the language construct we developed an ITIL metamodel as a
representation of all relevant concepts encapsulating concepts specialization to obtain
a perfect match, allowing the integration between ArchiMate and ITIL.
We proposed a set of integration viewpoints to enable stakeholders to focus on
particular aspects of the architecture related with ITIL, and to implement all ITIL
processes and functions, such as change management, as we will develop in the next
section.

143
4.4 CHANGE MANAGEMENT
Organizations are continually changing, namely their strategies and objectives, and
consequently, their business and IT. However, change is probably one of the most
misunderstood areas in EA
Despite all EA advantages, keeping information updated and manageable is
challenging. EA artifacts evolve over time, as well as their relationships.
In most organizations, IT artifacts in particular are constantly changing without
standard processes, concepts or notations in IT professionals personal notes, neither
into a common repository of information. The dynamic nature of such artifacts has
been a difficulty in keeping EA updated (Pedro Sousa et al., 2009). There are too
many changes, but, once outdated, an EA cannot be properly used.
Behind an architectural description, there is always a set of other concepts that must
be defined to ensure that the architectural description is properly understood, namely
notation, concept, model, view and viewpoint (Pedro Sousa et al., 2009). Therefore
questions arise related to what level of detail should one define artifacts and concepts,
which viewpoints to use, and what artifacts should each viewpoint represent. The
change management should reflect each of these questions.
For the domains with a high rate of change, such as business processes and IT, one
cannot assume to have valid viewpoint representations simply because the effort to
keep them up-to-date is too high. In other words, the current EA frameworks and
models do not capture the dynamic nature of organizations (Pedro Sousa et al., 2009).
Moreover, in order to perform optimally and to implement changes successfully,
organizations must operate as a unified and integrated whole (Dietz et al., 2013).
This section presents how we can use the dissertation proposal on a daily basis to keep
the EA updated. More than handle with the change, the ability to determine the
impact analysis and predict consequences is needed. We consider that any change in
the coverage scope of an EA should be carried out on a continual improvement basis,
considering that all changes must be recorded and managed in a controlled way. As
such, the focal point of change management process should be the whole
organization’s concepts, dimensions, and layers.
Reflecting changes into daily organization’s operations is where EA should come into
play, providing a better understanding of the effects of changes.

144
4.4.1 Change in TOGAF and ITIL
TOGAF carry out the change through Phase H (Architecture Change Management).
However, in TOGAF, change is barely predicted. Instead, Phase H initiates an
evolution cycle to identify change’s consequences, after they occur, as we can see in
TOGAF 9.1 “When changes are identified, change management will determine whether to formally
initiate a new architecture evolution cycle” (Open Group, 2011). With TOGAF principles, it
is difficult to ensure that EA is updated on a day-to-day basis.
Change conception is quite different in ITIL, where a change is defined as “the
addition, modification or removal of anything that could have an effect on IT services” (Cabinet
Office, 2011f). We highlight the reference to “anything” meaning the wide scope,
although this notion is not translated in ITIL processes, where changes are only
related to IT services. In the ITIL, a release is defined as a set of one or more changes.
In the context of our work, the difference between release and change is not important
and therefore we consider “change” as both concepts.
ITIL was developed with a focus on service delivery and support. As such, ITIL has
processes responsible for ensuring that artifacts’ information is updated. Change
management and configuration management are two of these processes.
Configuration management addresses the control of a changing IT infrastructure,
identifying the configuration items, the relationship between them, collecting and
managing documentation about the IT infrastructure and providing information
about IT infrastructure to all other processes (Bon et al., 2007).
In terms of change management, the previous version of ITIL lays out a foundation
based on CMDB, widening the best practices in the more recent versions to the CMS.
As the core of ITIL, these databases document all the relation of the organization’s
artifacts (documents, infrastructure, etc.), providing a well-known and defined
framework for the modification of this data when changes are made.
Changes require alignment maintenance and the capability to face what is needed.
Change management supports changes, and a data repository is used to determine the
changes impact.
Therefore, the ITIL’s service configuration management ensures that the
configurations under organization’s control are identified, controlled and properly
cared for throughout their lifecycle. The configuration management process ensures
the reliability of the data recorded and accessed in a common repository (CMDB), but
also provides coherent views of the architectures and their relationships by identifying,

145
controlling, maintaining, and establishing the relationships between elements. The
data stored supports the different ITIL processes, but also predicts organizations’
activities in a desired “to-be” state.
In this context, changes do not happen in isolation, they affect other (related)
components in the organizations’ dimensions.
We propose to combine the top-down traceability of TOGAF paradigm with the
change impact analysis keeping up-to-date data and viewpoints to disparate
stakeholders. EA and change management require a decision capability, so we must
have architects in the Change Advisory Board (CAB). As such, TOGAF guarantees a
consistency for the design and deployment of new products and services, addressing
business requirements. ITIL guarantees the consistency of enterprise architecture
through the use of change management processes.
This proposal is totally aligned with TOGAF since in ADM’s Phase H is mentioned
that a change management process could be related to the ITIL change management
process (Open Group, 2011). Obviously, it would make sense to “re-use” the ITIL
change management process for architecture changes.
4.4.2 Proposed Change Management
Considering that even a simple change may entail a major redesign of organisational
structures, business processes, applications, and technological infrastructure, we
should have accurate architecture models that enable us to various types of analysis,
defining the change impact. This insight helps stakeholders to design, assess, and
communicate the consequences of decisions and changes within and between these
business domains.
Performing such structural analysis implies “traversing” the architecture and taking
into account each relation. Its meaning will allow us to determine how the proposed
change might be propagated. For instance, if a service provided by an application
changes, every user of that service may be affected.
To predict the effects of change and respective modifications within an organisation’s
business and IT, it is necessary, but very difficult to obtain, an overview of these
changes and their impact on each other (Open Group, 2012).
Besides the part that change should only be instantiated by people with power and in
accordance with organizations’ objectives, we must be able to identify the change’s
consequences and to register them.

146
Until recently, many organizations only used spreadsheets to forecast the implications
of changes. Only few organizations use more sophisticated modelling and analysis
techniques, often based on simulation or workflow techniques, to predict the effects of
change (Eertink et al., 1999).
Concerns arise from the complexity that organization wide architecture viewpoints
may bring. Since organization wide viewpoints tend to focus on global views of IT
artifacts, rather than on the subset of artifacts that are relevant, reading and updating
organization viewpoints is more complex than it could be (Pedro Sousa et al., 2009).
Above we identified many reasons preventing organizations to have EA, and therefore
their viewpoints, up-to-date. In order to keep EA updated, one needs two basic things
(Pedro Sousa et al., 2009): information about what has changed; and rules to update
the EA accordingly. Such information exists in different source information of the IT
professionals, namely of those that were involved in the changes (Pedro Sousa et al.,
2009).
The architectures’ relations between the different types of dimensions, views,
concepts, and layers must remain clear, and any change should be methodically
carried through EA. These architectures need to be understood by different
stakeholders, each at their own level, making available different viewpoints
(Lankhorst, 2009).
We focus on viewpoints through integrated descriptions by means of architecture
models and the analysis of the changes’ impact. As such, models should be maintained
reflecting changes.
The viewpoints and the respective views should only have the detail level that the
management needs. In that sense, a view is a graphical representation depicted from a
viewpoint, representing the artifacts and their relations, which constitute the
organization. More granularity than needed, in the detail level, leads to increasing
management problems without added value. Therefore, viewpoints and respective
views should not be more complex than strictly needed, but should be automatically
propagated back organization-wide and to more complex viewpoints.
However, these depicted concepts in views, such as information systems, applications,
and components among others, should be clearly related, representing the same
amongst IT professionals. So, different IT professionals should use the same
referential, equally classifying the same artifacts and concepts. Even though, there is
no clear definition of which artifacts should be represented in each view. It is up to the

147
stakeholder to decide what is relevant and what is not relevant to represent/model in
each viewpoint (Pedro Sousa et al., 2009).
We may think that problems would be solved if IT professionals used a defined
ontology classifying artifacts and concepts, using standard processes, publishing
change, and updating information in a common repository.
To ensure that these essential aspects are discussed, a good architecture should clearly
show the relation of the architectural decisions with an organization’s business
objectives.
Moreover, a good architecture maintaining models is the main purpose of an EA, as a
well-defined architecture is an important asset to identify and manage necessary
changes, no matter what type of change, but all that can (and should) be reflected in
the EA.
Furthermore, these models should be used as evaluation support for impact of
changes. They offer a holistic perspective of the current and future operations, and on
the actions that should be taken for change impact.
However, all types of changes should be carried on through a defined change
management process. In an organization we have different types of change occurring
in different times and with different impact. Therefore, beyond a unique process
reflecting change in a common repository, we should evaluate and deal differently
with different types of change.
4.4.3 Types of Changes
Even though an architecture captures the relatively stable parts of business and
technology, any architecture will need to accommodate and facilitate change
(Lankhorst, 2009). Architectures may change for different reasons, but we can
summarize changes in three distinct areas:
• Business change may occur from a new strategy definition, change in
environment, or even from IT reflecting changes in the business. For instance,
new technologies may allow new business opportunities and therefore IT may
potentiate the business. However, the most common change is a new business
area that IT should support. In this case, IT changes due to business changes.
• Changes associated with projects. Every change due to a project
management might have a potentially high impact on the architecture, and
consequently in the organization. Since many of these fostered changes can

148
have high consequences and since each project has a scope associated, if a
change needs to occur we should have to predict the change and a previous
evaluation should take place.
• Service management changes are associated with IT’s change
management. Service management changes (often referred as the normal
change management process in IT) are basically any change occurrence in the
running live environment.
We start by the assumption that any change has a potential impact and risk with
consequences in the overall organization.
The impact can be defined as the effect measure within an EA, with possible direct
consequences to the overall organization. For instance, a change has a high impact if
all EA is affected and low impact if only an artifact is affected.
We define risk as a threat that a change has to the organization’s success. For instance,
a change has a high risk if the organization success may be severely affected, and low
risk if the change has negligible effect.
Therefore, change is an area in which we need to take careful consideration,
evaluating the risk, impact and all the respective consequences.
Other factors should be considered in change decision, such as cost and urgency.
However, since these factors do not affect the proposed change management in the
integration between TOGAF and ITIL, we will not consider them, because they are
out of scope of this dissertation.
As we saw in the previous subsection 4.4.1, the two well-known frameworks TOGAF
and ITIL deal differently with change. We should combine them in order to
effectively manage change.
From TOGAF and ITIL change characterization we summarize the type of change in
two large groups, depending on the relevance they promote in the EA, from impact
and risk evaluation:
• High relevance change – in this group we include the strategic changes,
the changes with architectural impact, and other major changes. This
type of change is usually characterized by a top-down orientation to enhance
or create new capability, which often results in the creation of new services or
changes in the existing ones. We propose three categories, according to the
impact and risks: Strategic, Architectural, and Major.

149
o Strategic change is characterized by a high impact and/or high risk,
requiring a decision from top executives. A strategic change produces
impact throughout the organization. Examples of strategic changes
are: the definition of new strategic goals, environment restrictions, or
the creation of a new business service.
o An architectural change supports new business initiatives that will
increase the organization position producing impact in multiple
services or organizational divisions. The need for architectural
changes may result from legislative requirements, to respond to short-
term market opportunities, or from public requirements. Examples of
architectural changes are: cost reduction initiatives, the change in a set
of IP addresses, a technology withdrawal, or the migration from
Windows NT Server farm to another technology.
o A major change maintains business viability but only affects a defined
organizational division, usually related to IT. Normally it contains
large areas of new functionalities, some of which may eliminate or
temporary fix identified problems. Examples of major changes are:
implementing/upgrading organization wide software, or a datacentre
reallocation.
• Low relevance change – A low impact change is usually a bottom-up
change carried on to correct or enhance a capability (operations and
maintenance) for infrastructure under operations management. It involves
changes in artifacts (so called “Configuration Items” (CI) on ITIL) without
architectural changes, keeping the majority of the previously defined
viewpoints and architectural models. Although this type of change is pre-
approved by the change management process, the impact of this change must
be reflected on the relationships that involve the affected artifacts. A low
relevance change is divided into two categories according to the impact and
risks: significant and minor.
o A significant change is characterized by low-risk from improvements
in usability of a service or adding new facilities. Examples of significant
changes are: the purchase and installation of a new server, or the
introduction of a new application to a small group of users.
o A minor change is where a small amount of impact and risk is
involved, such as a change in a CI for which the approach is pre-
authorized by change management. Examples of minor changes are:
the installation of one workstation, or the installation of a standard
word processor in a standalone workstation.

150
We assume that the creation of another type of change reflecting the organization
concerns is perfectly acceptable. The number and division of change’s types is not
relevant. However, we should have a criteria to differentiate the change’s type,
previously defining a classification schema that allow to categorize the different type of
change, as for instance the impact, the risk, and/or other relevant characterization
criteria.
We highlight that no matter what type of change they are all changes, and although
they happen in different architectural scopes, they should be managed according to a
defined change management process reflecting their impact on EA.
From change’s relevance identification, as for example from the following Table 22,
we may follow the defined process associated to each type of change. In each type of
change, we should also identify the affected viewpoints to predict the change before it
occurs. After that, the change should be reflected in the architectural repository, for
instance a CMS.
Table 22 – Matrix of Change Characterization
Risk
High Medium Low
Impact
High Strategic
BoD
Architectural
BoD
Architectural
BoD
Medium Architectural
BoD
Major
CAB
Major
CAB
Low Major
CAB
Significant
CAB
Minor
CM
BoD – Board of
Directors
CAB – Change
Advisory Board
CM – Change
Manager
Since the consequence of each change is different on impact and risk, the level of
decision responsibility should depend on each type of change. Although there may be
others, we consider three decision levels:
• A Board of Directors (BoD) – including the CEO and other CXOs that have
an active voice in strategic decisions and organizational orientation;
• Change Advisory Board (CAB) – a group of top executives who advises the
assessment priority settings and schedule of changes. The CAB may be also
composed by representatives of all branches within the IT organization;

151
• Change Manager (CM) – as the responsible for the change management
process that may require input from other teams or directors from other
organizational divisions.
We assume that it is not always possible to clearly identify the type of change. There
will always be “grey areas” between the types of change that we are facing.
An incremental table (for instance, Table 23) with the different types of change will
reduce the difficult to accurately classify each change.
Table 23 – Sample of Change Occurrence and Characterization
Strategic
(BoD)
Architectural
(BoD)
Major
(CAB)
Significant
(CAB)
Minor
(CM)
Change
Occurrence
Therefore, we propose the creation of an incremental table, with the different
occurrences of changes, connected to the type of change and thus linked with the
change decision maker.
As any change may have effects in the organization, we should manage and record
each change occurrence accordingly.
4.4.4 Change Management Viewpoint
The following additional viewpoint represents change management, showing how the
change management process is conducted by focusing on the connection to other
processes and to the EA repository, and also showing the different layers of change
intervention.
This proposed viewpoint is closely related to the ArchiMate Layered Viewpoint (Open
Group, 2012) used as support for impact of change analysis and performance analysis,
or for extending the service portfolio.
We propose this additional viewpoint (Table 24 and Figure 77) because there are
different types of changes, which are treated differently.
This viewpoint is more comprehensive and specific than the ITIL Process Viewpoint,
since a change assessment is needed for each change occurrence, and this assessment
is made at different levels. Therefore, we specify change management through a
specific viewpoint.

152
Table 24 – Change Management Viewpoint
Change Management Viewpoint
Stakeholders CEO, BoD, Analyst, Manager,
Designer, User, Customer
Concerns Understanding and evaluating
change effects
Purpose Designing, Deciding, Informing
Abstraction Level Overview; Coherence, Detail
The Change Management Viewpoint is used to show the high-level structure and
composition of the change management processes. Next to the processes themselves,
this viewpoint contains other directly related concepts, such as:
• Change assessment should be performed and, depending on each type of
change, a categorization should be performed in terms of impact and risk.
• The decision must depend on the level of evaluation by the respective role.
• The Layered viewpoint pictures the layers evaluated to change’s decision.
Figure 77 – Concepts and Relationships of Change Management Viewpoint

153
4.4.5 Summary of Change Management
One of the central motivations for EA in general is getting to grips with change as
architects and stakeholders want to take well-informed design decisions.
Critics argue that the field of change management is so vast that the term is practically
useless. However, not having any specification about how to implement changes and
how to predict change’s effects can lead to unmanageable organization with
unpredictable results.
To that end, we need to compare alternative designs, make decisions based on impact
and risk (despite other aspects we could consider such as cost, quality, and
performance) and know the impact of a change across all aspects of an architecture.
We propose to follow a change management process integrating TOGAF and ITIL
practices, clarifying the results and impacts of changes. This process should be based
on a repository that shows how artifacts are related, predicting the impacts, and
realizing what must be undone if problems occur with changes.
To the best of our knowledge, the problem of keeping up-to-date EA in an automatic
manner is an issue to be satisfied. Without an up-to-date EA we cannot present a view
as a valid viewpoint depiction.
Four main issues must be addressed: first, we should identify what has to be changed,
evaluating the involved implications; secondly, the update of information about what
has changed; third, ensure that the changes are reflected along information flow, from
the ones making the changes to the ones updating the repercussions; finally, the rules
to update the viewpoints depiction.
Our proposed change management allows moving a step forward by providing a
stronger approach to sustain models and methodologies.
The relationship between concepts along a defined metamodel allows determining the
implications of change top-down and bottom-up.
Summarizing, we may say that an effective change management process must at least:
• Use a defined process that can be reused;
• Ensure the recording, evaluation and processing of all changes;
• Identify and evaluate the impact and risk associated to each change;
• Clearly define the type of change and ensure that team members understand
the difference;

154
• Request for changes should pass through a centralized function to process
requests, typically the Service Desk function;
• Clarify the competence to handle to each type of change;
• Consider low impact changes that could be implicitly pre-approved with a
short evaluation.
4.5 SUMMARY
In this section we presented our proposal to the integration between TOGAF and
ITIL. We identified ArchiMate as the language that best enables the integration
purpose.
ArchiMate is the adopted modelling language for enterprise architecture and is fully
aligned with the TOGAF. Therefore, if we could use ArchiMate to model ITIL, we
could integrate TOGAF and ITIL through the same modelling language.
We compared TOGAF and ITIL identifying many similarities, some overlapping but
also contradictions. The integration of TOGAF and ITIL can promote synergies since
TOGAF guarantees a consistency for the design and deployment of EA and ITIL
guarantees the consistency through the use of standard processes.
We evaluated the integration between ArchiMate and ITIL mapping the ITIL’s
concepts into the ArchiMate metamodels identifying some ontological deficiencies.
We proposed an ITIL metamodel to model the integration between TOGAF and
ITIL. Using concepts’ specialization we achieved a perfect match of concepts from the
integration between ArchiMate and ITIL. The ITIL metamodel represents all
relevant concepts, allowing the integration between ArchiMate and ITIL and,
consequently, the integration between TOGAF and ITIL.
The ITIL metamodel is the basis to a set of integration viewpoints to focus on
particular aspects of the architecture related with ITIL, and to implement all ITIL.
We also propose a change management process integrating TOGAF and ITIL
practices and managing all types of changes, identifying, classifying, and evaluating
the involved implications. Our proposal change management process allows to keep
the EA updated.

155
5 DEMONSTRATION
This section corresponds to the “Demonstration” step of the DSR Methodology to
demonstrate that the proposal solves one or more instances of the problem (Peffers et
al., 2007).
We demonstrate the validation of our proposal in two ways. First, we present the
modelling of ITIL using ArchiMate defining ITIL models. We then present the result
of applying our proposal in a field study by integrating TOGAF and ITIL in the
“Centro de Dados da Defesa” (IT Department) of the Portuguese Defence Ministry.
5.1 ITIL MODELS
Although we already had the concept mapping (Gama, Sousa, & Mira da Silva, 2012),
we had to go further and demonstrate that it really could be used to model ITIL with
ArchiMate as the integration language.
From our integration proposal, we have already conceptually mapped the integration
between TOGAF and ITIL concepts, concluding that we can model ITIL with
ArchiMate. At this point, we already had the ITIL metamodel, with elements in each
of TOGAF layers, while the TOGAF metamodel is the ArchiMate metamodel itself.
We do not present all (26) ITIL processes for space reasons. Instead, we only show a
few examples to demonstrate the work done and the compliance with ITIL standards.
We started by analysing the official ITIL books, going through all its processes,
functions and concepts. Together with a co-supervised master student we published
several papers about our viewpoints to model all ITIL processes as a 3-model scheme
(Gama et al., 2012; Vicente et al., 2013b, 2013a): we started with an ITIL overview
with all five books to show services and processes (and from which books) that ITIL
provides; then, we zoomed into each one of the ITIL books, to model all processes,
events, functions, business objects, applications and databases; finally, we went down
for deeper fine-grained models representing each of the 26 ITIL processes.
This approach allowed to look inside each process, seeing individual activities, which
business objects are manipulated and what services they use and expose. These
models were chosen to show how ArchiMate could be used to model ITIL and to
show different views, directed to different stakeholders with different concerns. The
three level models are consistent since the processes inputs and outputs, business

156
objects, business events, business application, and infrastructure services are the same
but on different granularity levels.
Some of the proposed viewpoints use only ITIL elements to represent ITIL processes,
as they are described in the ITIL books. In this section we present several models
based on these particular viewpoints. These are the models that will be useful to
organizations for guidance and reference in ITIL adoption.
We used the ITIL Book Viewpoint (subsection 4.3.3) to model an ITIL overview with all
its five books. Figure 78 presents a part of this model, showing only the Service
Transition book to keep the image readable.
Figure 78 – Part of the ITIL Overview Model
Its use is to understand which services (and in which books) ITIL provides. However,
it should be noted that those are not IT services, but business services, since they
represent a general behaviour that is conducted by ITIL business processes, and not
its implementation.
It also shows the different artifacts and concepts used along layers, namely the
applications (and respective services) that ITIL uses to support its processes, and also
the infrastructure components (databases and services) that support those applications.
It provides a top view with ITIL core processes as a black box system that provides
services to the environment while using application and infrastructure.
A bottom level in ITIL modelling is achieved when we zoom into the ITIL books. We
have a second level model using the ITIL Process Viewpoint to model ITIL management
processes. For instance, Figure 79 shows some processes from the Service Transition.
In this figure we can see most of all its processes, events, functions, business objects,
applications and databases.

157
Figure 79 – Detail of Service Transition Process Model
Finally, we designed a deeper fine-grained representation and used the ITIL Process
Detail Viewpoint to model the Incident Management process (Figure 80). This allows to
look inside this process, focusing on its individual activities, which business objects
they manipulate, and what services they use and expose.
Figure 80 – Detail of Incident Management Process Model
These models were chosen to demonstrate how ArchiMate could be used to show
different ITIL views, aimed at different stakeholders with different concerns. Yet, the
three types of models remain consistent, since the processes inputs and outputs,
business objects, business events, business applications and infrastructure services are
the same but on different granularity levels.

158
Besides this 3-model pack, we produced a full set of models, one for each of the other
ITIL books. Together, our ITIL core representation includes the models for all the
ITIL 26 processes and 4 functions, built with the ITIL Process Viewpoint (Vicente et
al., 2013b).
The complete set of modelling representations is available as a high resolution PDF at
http://db.tt/oFKG9oWY.
These models represent our proposal for a formal representation of ITIL and a tool
for architects to use ITIL components and relationships to design ITSM
organizations. These models also allow to check for best practices’ compliance and
maturity, by building “as-is” models with the current organization’s ITIL processes
and “to-be” models representing the ITIL maturity level where the organization plans
to stand in the near future.
The proposed models show ITIL main concepts and relationships, mapped to their
ArchiMate counterparts. These models prove that we can model ITIL with
ArchiMate artifacts. However, to demonstrate the usefulness of these models in the
real-world, we needed a field study, which we got through the “Centro de Dados da
Defesa” of the Portuguese Defence Ministry.
5.2 FIELD STUDY
In order to show in practice how ITIL and TOGAF are related and how to integrate
both approaches, we realized a field study in an organization EA model containing
totally integrated ITIL elements. A field study should also demonstrate how our
viewpoints and models can be used to add value to real organizations, and therefore
to validate our work in practice.
The demonstration is based on work currently being developed in the “Centro de
Dados da Defesa” (CDD) of the Portuguese Defence Ministry (MDN).
5.2.1 Organization
CDD supports more than 3,000 users of the SAP system “Sistema Integrado de
Gestão” (SIG) from the overall Portuguese Defence forces (MDN, Navy, Army, Air
Force, and EMGFA) and all IT services delivered to over 800 users in the MDN
(Figure 81).

159
Figure 81 – Overview of Defence Domains
The CDD belongs to the Secretaria-Geral of the MDN, whose organizational
structure is presented in Figure 82.
Figure 82 – Secretaria Geral’s Organizational Structure
CDD has a top director (Secretário-Geral) and an executive officer (Secretário-Geral
Adjunto). Beyond CDD, there are other Services Directorates such as law and justice
(DSAJ), provisioning (UMC), finance (DSAF), planning (DSPC), human resources
(DSGRH), public relations (DSCRP), and SIG/SAP development (DSSI). CDD is the
unit that provides IT services and respective support to MDN 800 IT Services users,
plus 3,000 SIG users.

160
CDD has approximately 40 employees divided in four technical areas: support
(ATAU), communications and security (ATACS), operation and systems
administration (ATAOS), and systems and applications (ATASA).
These employees have good technical skills, know-how, and all have an ITIL
certification. All areas have defined competences and the technical support links the
other technical areas. The support technical area (ATAU) also ensures the service
desk function.
5.2.2 Historical Overview
About two years ago, a project was conducted to raise the enterprise architecture of
CDD. In the beginning, there was some difficulty to start and involve the employees.
Only with some organizational principles related to change management was it
possible to achieve some results from the project team, namely: presenting the EA
advantages; involving people in decisions; sharing and relating the elements managed
by each technical area; following BPMN to identify processes; and increase
transversally in the relationship between technical areas.
However, BPMN was insufficient to model the processes in a coherent way along
different technical areas, and even less along layers of the enterprise architecture.
Notwithstanding, we developed an architecture metamodel based on TOGAF
supported by IBM System Architect and the respective database, as the EA repository.
Each technical area contributed to identify the elements they managed and efforts
were done to relate those concepts. Some of the results are illustrative and presented
in Appendix H – Images from the Field Study. For example, Figure 117 and Figure
118 illustrate some of the modelling BPMN processes that supported services from
each technical area. At that time, each technical service area identified its services.
However, these services were identified with different levels of granularity, and only a
small part of the services were identified.
The network models, illustrated in Figure 119 and Figure 120 were well depicted as
most of the views had already been designed with MS Visio. Some additional effort
was done due to duplication of work, which was a big obstacle to motivate people.
Figure 121 illustrates some work done by ATAOS to represent the servers’
distribution, answering the needs of that technical area’s stakeholders.

161
Once all the information was loaded into the EA repository, it was possible to identify
and show some relationships between concepts, as illustrated in Figure 122.
Despite the initial good results, the architecture quickly became out-dated due to the
ineffective follow-up of governance policy needed to keep the project alive: technical
areas managed their assets in different information repositories; and the technical
support area kept information of CI separated from with EA repository. Finally, the
project was abandoned.
Some of the identified causes to the less positive results in the project are:
• Non-dedicated project team;
• EA repository without constant updates;
• The use of different repositories to manage CI’s and assets, without
communication or dynamic actualization between them;
• Different languages for modelling different layers;
• Modelling language (BPMN) insufficient to model coherently along different
layers;
• Different granularity modelling levels;
• Incoherence in the adopted metamodel;
• Absence of processes linking technical areas; and
• Unawareness of the advantages in using a single information repository.
Furthermore, the ITIL processes were designed without any integration with the EA
project. For example the CMDB only managed the IT assets while others CI were
managed in different repositories.
5.2.3 Current EA Project
After identifying the strengths of CDD and controlling the failure causes of the prior
project, we started a second EA project that is currently underway.
Due to the widespread knowledge of ITIL best practices in the CDD, they already
have in production: incident management, request fulfilment, problem management,
and service desk function. The CDD is currently increasing the number of adopted
ITIL processes by developing change management, configuration management, and
event management As such, any initiative should be based on this common knowledge
of practice based on ITIL.
Our proposal for integrating EA and ITSM through the integration of TOGAF and
ITIL aims to achieve the desired results.

162
Since BPMN was an insufficient modelling approach, we adopted a common and
single language to model CDD’s enterprise architecture. ArchiMate was identified as
the language that allows modelling consistently along different EA layers, and to
support the integration between TOGAF and ITIL.
As presented in our proposal, a single repository is vital to the integration purposes.
Therefore, we identified the information sources from all technical areas, namely the
ones needed to design the enterprise architecture. Finally, we realized that the only
way to link the different technical areas was using the same ontology and processes. In
this case, our metamodel answers these needs as ArchiMate and the proposed ITIL
viewpoints offer all the models needed.
Therefore, based on the lessons learned, a few months ago we started a new project to
design the enterprise architecture for CDD. We proposed a sequential method with
the following initiatives:
1. Presenting the conclusions of the previous project to key decision makers, to the
involved team, and to the key users.
2. Explaining to the identified stakeholders the objectives of this second project,
namely the principles, methods, and models to be used.
3. Creating a dedicated team and defining the competence and responsibility of a
board of directors with people from all technical areas. The board of directors will
have particular importance in the change management processes.
4. Building a model for each layer. For this step, we proposed ArchiMate elements to
create a baseline model in each layer’s architectures, modelling different
organization viewpoints, and filling the needs from the different stakeholders,
namely: the people and roles viewpoint, the application viewpoint, the data
viewpoint, and infrastructure viewpoint.
5. Identifying the different information sources used to manage information under
each stakeholder responsibility, and integrating this information in a single
repository to integrate the information. This integration allows identifying and
visualizing the relationships among concepts and artifacts.
6. Creating a service catalogue with two views: a business service and an IT service.
To each service, a model showing how services are realized should be designed,
depicting the concepts and relationships along layers using the ITIL Service
Viewpoint.
7. Modelling ITIL processes using ITIL viewpoints, using the proposed ITIL models
and bridging them to the baseline architecture. A gap analysis will be performed
for identifying what has to change in the organization’ layers to achieve the
required target integration architecture. For each ITIL process, modelled with our

163
proposed models, we will perform a gap analysis using the ITIL Compliance
Viewpoint that uses an assignment relationship to link core elements to the proposed
ITIL elements.
8. Identifying a tool to support EA visualization in accordance to defined pre-
requisites.
9. Defining a change management process to be followed, focused on keeping EA
updated. Beyond the process definition, the change management process implies
the definition of roles to support different decision points.
In the rest of this subsection we detail some of these initiatives.
Project Preparation
The results from the previous project were not as good as CDD expected. After an
initial enthusiasm, the people involved were quite disappointed. Therefore, it was
needed to recognize the weakest points. Also, there was a need for hierarchical and
political support to this new initiative. A new project implying operational changes,
the adoption of a new approach, and an ontological model are all disruptive changes
in the organization that may cause some change resistance.
It is a duty of organization’s directors, especially those related with IT, to provide the
means to the people in an organization to internalize its ontological model. Moreover,
it is an ethical necessity for bestowing authorities on the people in an organization to
constantly validate the correspondence of the model with the operational reality (Dietz
et al., 2013).
The conclusions of the prior project were presented, including what was needed from
lessons learnt.
A small team was then created, including two dedicated people, from the beginning of
the project. Also roles and competences were defined, namely the ones related to the
change management process.
Layered Architecture
To develop a layered architecture we started by following a bottom-up approach. We
aim to address people’s needs by modelling and showing the elements they managed
in an integrated way.
Some tasks were time consuming, namely the time spent adjusting unstructured
information and manually guarantying the information quality. However, this activity

164
was vital as people cannot lose confidence in their information, and we needed to
show short-term results.
Regarding the information integration, we identified the information sources from
each technical area. We identified several and distinct information sources, from
highly structured information such as Active Directory (despite some inconsistent
information), less structured such as modelling tools (BPMN processes), or even
documents such as Microsoft Office (Word, Excel, PowerPoint and Visio), among
others.
Information integration must be made from structured sources, therefore, integrations
with unstructured sources require prior structuring work (Pedro Sousa et al., 2011).
To structure the information sources we had to clarify the semantics of each used
artifact type and also the respective relationships. The adoption of a recognized
metamodel was crucial.
Hence, we identified the information sources from each technical area in the defined
metamodel. With a few meetings with each of the technical areas, sources of
information were identified, clarified, and selected.
In this phase we identified 12 main sources of disparate information that had to
integrate. Figure 123 to Figure 128 on Appendix H – Images from the Field Study
(Current Project) illustrates samples of the different sources of information, including
some scanned documents (some figures are intentionally illegible due to confidentiality
issues).
Each technical area manages information relating to their respective functions and
technical competencies. This information was not integrated or even shared, as each
technical area had its own database with related information.
From the identified information from each technical area, we developed the
architectural layers: infrastructure architecture involving the servers and networking
views; data architecture with databases and instances; and applications architecture.
Figure 83 illustrates some parts of the infrastructure architecture models.
More than modelling each of the architectures, we were able to identify the different
sources of information.
We also identified other sources of information related to SIG-SAP, and we developed
connectors to keep some information updated.

165
Figure 83 – Examples of Models from the Infrastructure Architecture
We then used our proposed viewpoints to model the process to update the
information, the ITIL Process Viewpoint. As we can see in the following Figure 84, every
technical area has a configuration manager responsible for maintaining the
information needed to manage their respective technical area.
The configuration auditor is responsible for the process, and audits the overall
process.

166
Figure 84 – Service Asset and Configuration Management
Service Identification
As stated before, we defined our metamodel by focusing on services delivery. We
considered each service as one of the CDD outputs, and from each service we clarified
the activities’ sequence (processes) that delivers these outputs using the ITIL Service
Viewpoint, which allows to identify applications used, information accessed or created,
and support technologic infrastructure.
Figure 85 – Overall CDD’s Service Catalogue
Defining the services was challenging because, although ITIL is a set of best practices
based on the service lifecycle, in ITIL it is not clear how to create a service catalogue
from scratch.
Figura 1 - Decomposição das categorias em Serviços CDD
A Figura 2 apresenta o meta-modelo que estabelece o relacionamento entre os conceitos
subjacentes ao Catálogo de Serviços e que tem por base a Arquitetura Organizacional do
Centro de Dados da Defesa.

167
We created our service catalogue from our incident database using a reverse
engineering process (Rosa et al., 2012; Gama et al., 2013). Therefore, we avoided the
common error of developing a service catalogue based on IT services. Instead, the
services were identified from user language, and so from the user in a bottom-up
approach.
Nowadays, our service catalogue is an official document from which our activities are
developed (Figure 86). Each service has an individual description and
characterization, with SLAs and IT services that support that service.
Figure 86 – Partial Detail of CDD’s Service Catalogue
ITIL Models
The proposed architecture is based on the services provided. Each service was
modelled with ITIL Service Viewpoints. Since each service has a provider, the ITIL Service
Provider gives a view of each provider to each service.
From our ITIL Service Catalogue Viewpoint, we have an overview of all the IT services
provided and how these services are supported, complementing this viewpoint with
the ITIL service viewpoint.
Figure 87 presents an example of a service’s model using the ITIL service viewpoint.
Each service is decomposed along layers, from the business to the technology layer.
The Secretaria-Geral has its organizational structures in two locations. Most of the
services directorates are in the Restelo location. The technical areas and functions of
CDD are mainly located in Olivais.

168
Figure 87 – Example of a Service Viewpoint
To map the location dispersion we used the ITIL Service Provider Viewpoint, identifying
who and where the services are handled and provided.
Figure 88 – Service Provisioning, including Provider Location
We also wanted to show how to use the proposed architecture to assure compliance
with ITIL best practices.
We used the ITIL Compliance Viewpoint that takes advantage of an assignment
relationship to link core elements to the correspondent ITIL elements from our
models. In Figure 89 we present this viewpoint applied to CDD’s Event Management
process.
In this model, we can ascertain that despite the existence of monitoring tools, the
generated events are not processed. The event management process did not exist and
the logs generated by the monitoring tools did not generate incidents.

169
Figure 89 – Event Management process using ITIL Compliance Viewpoint
The CDD had a good opportunity to implement the event management process. As a
result, following our compliance approach, it was possible to identify a change for
improvement. This viewpoint showed that the existing infrastructure at CDD was not
compliant with ITIL best practices.
This model is just a small example of the expressive power of proposed integration. In
fact, this can be done to every ITIL process and any scope can be used. Therefore,
this can become a valuable tool to demonstrate compliance with ITIL and other
standards for IT Service Management, such as ISO20000.
Development
With only a few meetings with each of the technical areas, 12 sources of information
were identified and selected. We then imported the information into the common
repository, integrating all identified information sources scattered throughout the
technical areas by introducing the information directly into the information
repository.
We used the Enterprise Architecture Management System EAMS (www.link.pt/eams)
to load our metamodel, access the overall information and visualize the different
viewpoints. The EAMS tool’s principles are defined in (Pedro Sousa et al., 2009).
We loaded our metamodel to EAMS, defining the core concepts and their respective
relationships. After having identified the information sources, structured the

170
information, and defined the relationships, we imported the files (most in CSV or
XML formats) to the CMS, with information from the different sources of the CDD’s
technical areas.
We also imported textual information from various information sources such as Excel
sheets, Word documents, Visio diagrams, among others. All this disperse information
was loaded into a centralized repository. We used EasyVista’s CDMB to store the data
and EAMS to generate architectural viewpoints and views.
All information related with MDN’s people was kept in the Active Directory (including
name, contact, department, and roles).
As mentioned before, beyond the information that is stored and updated in the CMS,
there are other information sources, such as information from the Active Directory and
information related to SIG/SAP users.
All information sources were kept updated in accordance to the proposed change
process.
Thereafter, we created different profiles to CMS access, allowing each area to access
and manage only the information that concerned that area.
Information related to systems administration is managed directly in the configuration
module of EasyVista, as well as the information related to servers, network equipment,
applications, and databases.
After presenting a first result from the relationship between artifacts, showing the
different viewpoints, we linked the EAMS to the CMS data sources.
Previously, we defined and implemented with the stakeholders the appropriate views
answering their needs. As mentioned, we used well-established viewpoints (provided
by ArchiMate and proposed for ITIL), both supported by EAMS. We found that most
answers can be found with these viewpoints, allowing the navigation between
representations according to stakeholders’ concerns.
The Figure 90 represents a generic overview of the adopted technical solution to
proposal’s implementation. Regarding the information integration, we imported the
information into the common repository, integrating all identified information sources
scattered throughout the technical areas to avoid introducing the information directly
into the information repository. All information is uploaded to the EAMS repository
through connectors with the different information sources. Everyone that has access to
the Defesa’s intranet can access the EAMS.

171
Figure 90 – Overview of the Implemented Solution
Figure 91 presents the conceptual adopted solution. The left side of Figure 91 shows
some of the scanned documents loaded into the CMS.
Figure 91 – Overview of the Conceptual Solution
CM
S
EAM
S
Database
s
Technologic Infrastructure
Network and Connectivity
Organization Structure Architecture Repository

172
The centre of Figure 91 shows the information provided by the CMS to EAMS
visualization purposes.
Considering the subject of the CMS, one of our tasks was to prepare a repository that
supports the evolutionary vision of the architecture. The CMS keeps the information
describing the organization and enabling the automatic generation of architectural
views.
Therefore, we had to identify, define, and implement the graphical models that
represent the stakeholders’ interests in the enterprise architecture. A key aspect is that
these models must be generated automatically.
Whenever the organization already has the processes to maintain and update a
particular source of information, one should provide the automatic import mechanism
to integrate it. As presented below, our proposed change management process (see
section 4.4) was applied in order to keep information up-to-date.
Results
So far, the results achieved are quite interesting, allowing us to provide consolidated
and updated information to the various technical areas through views of the
architecture:
• Consolidated as we have results from the information provided from
different areas and from disparate sources; and
• Updated as we have results from information sources maintained and
updated by the stakeholders from the different technical areas through the
proposed change management process.
Each technical area contributes with information that relates with information from
other areas, entailing an important transformation in the organization, with
homogenized languages and tools.
The metamodel was derived from the service orientation, reaching a model with 16
concepts. To populate these concepts entities, we have identified 12 sources of
information.
The right side of Figure 91 presents examples of the architectural views generated by
the EAMS tool. In addition, to the more traditional static visualizations, the solution
allows interaction with the representations.
Stakeholders may interact with the created view by selecting and inquiring
information about artifacts and navigating between views.

173
5.2.4 Change Management
As stated before, keeping the EA updated is challenging but the only way to have a
“tool” not only to predict the “to-be” state but also to allow the operational
organization management on a daily basis.
Since TOGAF and ITIL deal with change management differently, we proposed a
change management process (see subection 4.4) entailing the best of the two
approaches.
Figure 92 – Change Management Process using the Respective Viewpoint
As such, we considered that any change with results reflecting in the EA should be
previously evaluated, registered and saved in the respective information repository.
A change assessment should be performed and, depending on each type of change, a
categorization should be performed in terms of impact and risk. The decision must
depend on the level of evaluation by the respective role.
Following the Change Management Viewpoint, we address the change issue depending on
each type of change. Figure 92 illustrates the adopted change management process.
Table 25 shows how we faced the demand for accurately classifying each change and
diminishing the uncertainty in change’s classification. The type of change is
dependent on the relevance that change promote in the EA, from impact and risk
evaluation (see Section 4.4.3)

174
Each change is characterized and registered in a table similar to the Table 25.
Identifying the type of change allows to follow its respective process in order to keep
information updated, and consequently the EA updated.
Table 25 – Change Characterization
Type of Change
Change Occurrence Strategic Architectural Major Significant Minor
Implementation of a
corporate business
application
X
Moving a computer
room
X
The purchase and
installation of a new
server
X
The application of a
"patch"
X
Installation of a new
printer model
X
Change in virus
definition
X
Introducing a module
in application
X
Changing a module of
a critical system
X
Changing the full IT
architecture
X
Changing the
business
X
New service X
Change service X
Process Change X
Physical database
changes
X
Upgrade of a PC X
Cost reduction
initiatives
X
The definition of new
goals
X
Creation of a new
business service
X

175
Change in a set of IP
addresses
X
Datacentre
reallocation
X
Server replacement X
When implementing this process, we faced some problems, particularly at the
beginning:
• The minor changes were not always registered to increase the speed of change
and because some people thought that these are negligible;
• There was some difficulty to get strategic and architectural changes due to
problems in attaining availability from the Board of Directors to change advice
and authorization;
• The overall change management process was not completely followed,
especially at the beginning;
• We had to face some resistance from people in sharing and updating
information in a common repository.
5.2.5 Summary
The work that supports the field study is not finished. However, we already identified
advantages in the current project.
Service orientation allowed the identification of activities from disparate Technical
Areas, identifying transversal and common processes. ArchiMate is the language that
allowed modelling along different EA layers but also through all Technical Areas.
The identification of information sources and the relationship among concepts
allowed the creation of a virtual single information repository. Instead of disparate
information sources, managed separately, the relationship between information items
was mapped.
The adoption of a unique approach and common language enabled the raise of a
definitive EA in the CDD, promoted the creation of synergies and also the use of the
EA in an operational way.
The proposed Change Management process allows to handle with any type of change
homogeneously and reflecting on keeping the EA updated.

177
6 EVALUATION
This section corresponds to the “Evaluation” step of the DSR Methodology, where we
evaluate our proposal. A proposed solution is complete and effective when it satisfies
the requirements and constraints of the problem we want to solve (Hevner et al.,
2004).
Several evaluation methods can be followed. To systemize approaches to evaluation
we used two main criteria: analytical and empirical evaluation approaches (Fettke &
Loos, 2003). We developed an analytical evaluation on theory-based perspectives and
logical conclusions from related work and prior results. The evaluation components
proposed are illustrated in Figure 93.
Figure 93 – Evaluation Components
First, we start by using Wand and Weber (Wand & Weber, 1993) ontological analysis
method to evaluate our proposal. Second, we will use Moody and Shanks framework
(Moody & Shanks, 2003; Moody et al., 2003).
Besides the evaluation of our proposal through appropriate methods and frameworks,
we also evaluated our proposal through practitioners in terms of relevant quality
attributes. We interviewed ITIL professionals to assert the models’ utility and
correction, and developed an evaluation of practical experience from practitioners
that used our proposal as a business case. We used a field study to demonstrate the
proposal and evaluate the applicability of our research.
ArchiMate
ITIL TOGAF
Ontological Evaluation
Wand & Weber Method
Metamodel
Real-world
instantiation
Action Design Research
Interviews
Field Study
Model Evaluation
Moody & Shanks Framework
Scientiﬁc
Publications
Viewpoints
Models

178
6.1 WAND AND WEBER METHOD
We have already performed the evaluation of concept mapping between ITIL and
ArchiMate in Section 4.3.1, so in this section we analyse the results achieved.
We performed the analysis according to two criteria: completeness and clarity. This
analysis was based on the Wand and Weber (Wand & Weber, 1993) ontological
evaluation of grammars method, where we compared two sets of concepts to identify
four ontological deficiencies by: Completeness, Overload, Redundancy, and Excess.
The amount of concepts in ITIL that have no representation in ArchiMate defines the
lack of completeness. Clarity is a combination of redundancy, overload and excess of
concepts. Lack of completeness can be a serious issue, while lack of clarity can make
the mapping unidirectional and hard to reverse.
We can say that our mapping is complete, because there are not any concepts from
ITIL without ArchiMate representation.
As for redundancy, there was more than one ArchiMate element to represent an
ITIL concept (see Table 10 for further details). This happens because ITIL is not very
specific on application and infrastructure layers’ descriptions. The problem with
redundancy is that the “correct” ArchiMate concept had to be chosen according to
context and experience, and although this choice is rather easy for human architects,
it can be a serious problem for automated model transformations. With the
ArchiMate specialization on ITIL, the problem was overcome and the mapping is not
redundant.
We find excess, as ArchiMate has concepts that are not defined on ITIL as meaning
or representation. Therefore, we identified some ArchiMate concepts without an ITIL
representation, namely “System Software” and “Representation”. However, we can
say that our mapping is excessive but modelling consequences will not be expected.
We also had overload when there were several ITIL concepts to only one from
ArchiMate (see Table 12 for further details). This happens because, as we mentioned
before, ITIL does not explicitly define or identifies concepts mainly on the application
and infrastructure layers’. This deficiency can lead to problems if we ever wanted to
do the opposite process: to go from an ArchiMate model back to ITIL again. To
avoid this problem, with our proposed ArchiMate specialization on ITILthe mapping
is not overloaded any more and every first set element is mapped to exactly one
second set element, allowing an eventual reverse mapping.

179
As a conclusion, although we have found instances of deficiencies, they seldom occur
and their effects were effectively eliminated through specialization of ITIL concepts.
In fact, on redundancy, the few problems were minimized through ITIL specialization
in the more important modelling concepts. As for overload, specialization minimizes
this deficiency, but the mapping can always be reversed if we annotate the ArchiMate
object’s properties with the name of the ITIL concept, which may raise ambiguity. As
for excess, once we specialise ITIL in ArchiMate modelling representation it does not
actually bring a problem at all.
6.2 MOODY AND SHANKS FRAMEWORK
The Moody and Shanks framework provides the necessary input to use the data
model quality factors framework (Moody & Shanks, 2003; Moody et al., 2003) to
evaluate some factors of the constructed artifacts.
We chose this evaluation framework because the definitions of quality factors are very
accurate and refined, making the distinctions between quality factors completely clear
and allowing a perfect evaluation. The factors proposed and analysed in the quality
framework were (Moody & Shanks, 2003; Moody et al., 2003) :
• Completeness refers to whether the model contains all user requirements.
We did not find any correct and/or relevant concepts about the domain, not
included in the model. So, we can say that our models contain the
requirements, because they include the relevant elements and relationships to
describe ITIL concepts and processes.
• Simplicity means that the model contains the minimum possible entities and
relationships. All the concepts and relations used in the metamodel were
textually described in the ITIL Glossary of Terms, Definitions and Acronyms
(OGC, 2007) and are mapped to the well-known standard ArchiMate.
We can also claim simplicity because we focused about developing a set of
viewpoints that focuses on representing relevant information to the identified
target stakeholders.
• Flexibility is defined as the ease with which the model can reflect changes in
requirements without changing the model itself. Although this quality factor
had an almost negligible influence on perceptions of quality, it has paramount
importance in reference models.

180
A good reference model must be extensible and evolutionary. Given the
abstraction of the reference metamodel, viewpoints and models were easily
deepened and adaptable to diversified target stakeholders answering different
needs. We also identified flexibility because parts of the models can be
dropped out according to organization needs, without affecting the overall
outcome.
• Integration is defined as the consistency of the data model with the rest of
the organisation’s data. Lack of integration leads to problems of complex
interfaces and problems consolidating different interests and stakeholders,
which can have high costs for the organisation.
Concerning integration, one of the goals of representing ITIL in ArchiMate
was actually to allow integrating its models with the organization’s EA
representation, which was achieved. The model presents several viewpoints
from different parts of the organization, and successfully relates them at the
business, application and technology layers.
• Understandability is defined as the ease with which the concepts and
structures in the model can be understood. This is the most influential quality
factor, suggesting that understandability has a much greater influence on
judgements of data model quality than other factors, reflecting the fact that
models are intended as a way of communication.
A key claim from ArchiMate is based on the understandable structure and
concepts that it encompasses. For that matter, the use of ArchiMate as the
ontological construct presents an advantage for modelling architectures. Also,
the use of multiple viewpoints clarifies the rationale of the metamodel.
The concepts and structures used are all from ITIL, TOGAF and ArchiMate,
which are easily recognizable for people in these fields.
• Implementability is defined as the ease with which the model can be
implemented within the time, budget and technology constraints of the
project. The main claim of this research is to provide a reference concerning
the integration between TOGAF and ITIL.
For implementability we demonstrated that the models can be used in a real
field study with expected results.

181
• Integrity is the definition of business rules or constraints from the user
requirements to guarantee model integrity. This quality factor was originally
included as part of completeness, as they form part of user requirements.
The abstraction of the constructed integration metamodel does not specify
constraints. Nonetheless, it respects the accepted rules and constraints of ITIL,
namely those that address the processes to be implemented and their business
objects, application and infrastructure dependencies.
• Correctness is defined as whether the model is valid to the rules of the
modelling technique (i.e. whether it is a valid model). This includes
diagramming conventions, naming rules, definition rules, rules of composition
and normalisation.
This quality factor is evaluated in terms of the number of errors in the use. In
Section 4.2 we described the concepts that have been used in the development
of the integration metamodel.
We have followed best practices from the ArchiMate specifications to design
and relate concepts using the viewpoints that better portray the structure and
behaviour of the reference metamodel.
Our ITIL models were built by a method that mapped every ITIL concept to
the correct ArchiMate one, followed by its representation according to every
ArchiMate rule and convention. Based on these arguments, we can affirm that
the proposal is valid.
The quality management framework was used to conduct a quality review of the ITIL
metamodel. The review was conducted over 13 interviewed from different areas, skills
and nationalities, but all with a strong ITIL background.
Figure 94 summarises the results of the Moody and Shanks evaluation. Each quality
factor was rated on a scale of 1 to 5 (5=Excellent; 1=Poor). The chart shows that the
model was overall well accepted. Less positives factors were the Understandability and
Integrity. Once the modelling was made using ArchiMate, a previous explanation is
required to a better comprehension of the language for those that do not know the
language.
The lower capacity of ArchiMate to model business processes lead to a less positive
result in this factor.

182
Figure 94 – Results of Moody and Shanks Evaluation
6.3 ACTION DESIGN RESEARCH
Design Science Research (DSR) emphasizes the importance of evaluation. However,
little work in the DSR arena has addressed the choice of strategies for evaluation. On
the other hand, evaluation activities and methods typically occur after the
construction of an artifact (Pries-Heje, Baskerville, & Venable, 2008).
Pries-Heje et al. expand evaluation choices for DSR arguing that designed artifacts
must be analysed as to their use and performance as possible explanations for change
and improvements in the behaviour of systems, people and organizations, e.g. through
case studies (Pries-Heje et al., 2008).
In fact, DSR pays scant attention in the shaping of artifacts by the organizational
context and the artefact’s value comes from the interaction with the organizational
context (Sein et al., 2011).
Current DSR is based on stage-gate models in that they separate and sequence
building and evaluation. Thus, they do not support the conditions necessary for
generating knowledge about the ensemble artifact through design. The use of a DSR
methodology leads to an initial prototype. However, the shaping of design principles
over multiple artifacts versions through intervention and evaluation is not supported
by this methodology (Sein et al., 2011).

183
Evaluation is generally regarded from one of two perspectives: in the ex ante
perspective, candidate solutions are evaluated before they are chosen or implemented;
in the ex post perspective, a chosen solution is evaluated after it is acquired or
implemented (Klecun & Cornford, 2005).
In the ex ante evaluation, the artifact is evaluated on the basis of its design specification
alone, dominated by the economic concerns of whether the system or technology will
be worth its costs. In other words, the ex ante perspective offers the possibility to
evaluate prior to undergoing the risk effort of building an instantiation of the artifact
(Pries-Heje et al., 2008).
The ex post perspective offers the possibility of evaluating the instantiated artifact in
reality, not just theoretically or hypothetically. The ex post evaluation methodologies
are characterized along two rather different dimensions: the setting dimension,
distinguishing real settings from abstract settings; and quality measures, with
automatic qualities distinguished from quality measures that have a basis in the
opinions of human subjects (Yang & Padmanabhan, 2005).
DSR evaluation approaches are also classified into two primary forms: artificial and
naturalistic evaluation. Artificial evaluation designates an evaluation of a solution in a
non-realistic way. Naturalistic evaluation explores the performance of a solution in a
real environment, such as within an organization (Venable, 2006).
Naturalistic evaluation is always empirical and may be interpretivist and/or positivist.
Naturalistic evaluation methods include case studies, field studies, surveys, interviews,
and action research (Pries-Heje et al., 2008)
The evaluation of our proposal was conducted through interviews and action design
research in a field study. So, besides the interviews evaluating the ITIL metamodel,
the results come from real settings in a real environment, in which the quality is
judiciously evaluated from the collection of subjective opinions of the users. This
naturalistic evaluation embraces all of the complexity of human practice in a real
organization.
6.3.1 Interviews
We interviewed 13 specialists from different areas, although all had in common a
strong ITIL background, asking questions and gathering feedback according to their
field of expertise (Vicente et al., 2013b).

184
The interviewed people were professionals with distinct occupations, from diverse
nationalities and countries, including PhD students, university professors, researchers,
enterprise architects, managers and process owners at distinct, different sized
organizations.
Along the interviews, the same vision of ITIL as just a process architecture was very
present amongst the majority of our interviewees. In fact, when introduced to the
suggestion that the ITIL books also mentioned architectural dimensions, which could
be represented and modelled, our subjects would frequently turn sceptical and doubt
our claim.
However, when we finally showed them the models, their opinions promptly changed.
“Never had thought of ITIL this way”, “amazing how you can look at an entire book
in just one model” and “now we can finally see which are the services ITIL offers to
the environment” were some of the sentences they used. They all agreed that this
overall architecture vision would benefit ITIL implementation.
The remainder of the interviews served to present our motivation, explain our models,
our mapping method and the reasoning process behind it, and gather ideas and
suggestions for further work.
At the end of the interviews, we asked the interviewed people to fill out a six question
multiple-choice survey about our work.
The questions were the following:
1. Comparing with other ITIL graphic models you know, how do you rate this
one?
2. How do you classify its utility for someone who is leading the ITIL
implementation on an organization?
3. How do you classify its utility for ITIL validation?
4. If all ITIL books and processes were modelled this way, would you use it in
your organization?
5. How do you classify its utility for stakeholder communication?
6. How do you classify the models’ correction?
The multiple-choice answers had 5 levels and ranged from “1” (None/Poor/No) to
“5” (Very Useful / Very Good / Always). Figure 95 presents the average rating for
each question.
Strangely, we see that the lowest score is in the question where we ask if they would
use the models, while the highest is where they assert the models’ utility for ITIL

185
practitioners. When asked about this paradox, subjects commonly answered that
albeit impressed with the models, they already had a set of processes, tools or methods
for their practice. Although out of the scope of this dissertation, one could see these
answers as evidence of how organizations resist changing even when they truly believe
the new way is better.
Figure 95 – Questionnaire Results
Finally, we also want to point out that by the nature of ITIL itself (a set of best
practices) we are aware that true model validation will probably never occur.
Therefore, our goal was instead to ensure that our models reflected ITIL processes in
general, according to how practitioners conceive and understand them. We do wish
however that these models are further assessed and evaluated by the ITIL community
in order to make them closer to the overall consensus of what is ITIL and how its
processes’ work.
6.3.2 Field Study
To the evaluation from a field study, we followed the evaluation strategic framework
(Pries-Heje et al., 2008) answering three main questions:
• When does evaluation take place?
The evaluation was ex post, incorporating aspects such as the focuses on evaluation
of an artifact that reflects not only the theoretical precursors and intent or
research, but also the influence of users and on-going use in organizational
context.
• What is actually evaluated?
We evaluated the four DSR products (Figure 29): the adopted language
(construct) specifying the modelling primitives implemented by the ITIL

186
metamodel and ITIL viewpoints (model), the followed process (method), and the
proposed solution applied in a business case (instantiation).
The goal of this evaluation is to allow the refinement of the artifact as it is shaped
and reshaped by the use context.
• How is it evaluated?
A naturalistic form made the evaluation. We used Action Design Research (ADR)
combining theory with practice, evaluating the artifact by implementing it in an
organization as a field study. ADR contributes for further understanding of
developed artifacts through the development in organizational context and
reflecting on the process (Sein et al., 2011).
From ADR we highlight two principles: Reciprocal Shaping, emphasizing the
inseparable influences mutually exerted by the artifact and the organizational context;
and Mutually Influential Roles, pointing to the importance of mutual learning among
the different project participants, combining knowledge of theory with practitioners
experience and organizational work practices (Sein et al., 2011).
In other words, ADR emphasizes that the artifact should reflect not only preliminary
design created by research, but also its on-going shaping by organizational use,
perspectives and participants. Another relevant principle from ADR is the
Formalization of Learning.
The practitioners of this practical experience were the people involved directly or
indirectly in the project at CDD.
At the beginning, most people were quite sceptic. First, because they already knew
how to model processes using BPMN. Second, they knew about ITIL and had never
seen an entire modelling project using the same language.
People with EA background were more receptive to ArchiMate as a modelling
language, than people from ITIL. They already used modelling languages to manage
their needs, often UML and ad-hoc models, but they did not use a single language to
model everything.
However, the first models were presented with good results due to their quality since
they have a clear relation between the model and the used language. The models were
correct and answered their needs. After all, people recognized utility and even
completeness, as the models answered their management needs.

187
On the one hand, correctness was recognized as there were not any identified needed
concepts that were not included in the metamodel. On the other hand, we verified
that some teams used more concepts from the standard, and modelled with more
detail than other teams, so the models do not always have the same granularity. In the
future, we should do some efforts to standardize the modelling granularity and the use
of the same level of ArchiMate’s standard concepts among people from different
teams.
Once learned, the modelling language was valid to model and to communicate among
technical areas, despite some controversy in some model’s interpretation due to
different opinions related to models quality. However, most times, the controversy was
related to the lack of the model’s detail, and not to the interpretation of models.
The integration between TOGAF and ITIL using a single modelling language and,
mainly, a single repository to keep and manage the information related to their needs,
resulted in a well-received solution.
The proposed integration between ITIL and ArchiMate also resulted in an integration
ontology, supporting and unifying a common representation of ITIL and ArchiMate,
as a formal taxonomy, and the sharing, reuse and interchange of ITIL best practices
in all organisations’ services
We may conclude that the expressed concepts and their relationships have syntactic
validity and provided the model’s validity too. Our proposal allows to solve the
identified problems with pragmatic quality. Hence, in the future we intend to evaluate
the proposal in a group of practitioners from disparate organisations.
To allow a quantitative analysis, we should have attributes that quantify measures
associated with the models. The nature of these measures and attributes may vary
depending on the needs of the concrete analysis technique used (Meertens et al.,
2012). Then, efforts should be developed to enable the proposal’s quantitative analysis
as future work.
6.4 SUMMARY
We evaluated our proposal following several evaluation methods. We started by
evaluating the integration between TOGAF and ITIL. To evaluate the ITIL
metamodel we performed the ontological evaluation of concepts' mapping from Wand
and Weber.

188
The ITIL metamodel was also validated through the model evaluation framework
from Moody and Shanks. We also developed Action Design Research evaluation
through Interviews and a Field Study. We interviewed practitioners with strong ITIL
background from different areas evaluating the ITIL metamodel, the ITIL viewpoints,
and the modelling of the overall ITIL framework using the ITIL metamodel. The
achieved results were quite interesting validating our proposal through the developed
evaluation.
Finally, we are currently applying our proposal in a Field Study. Despite the results
are neither final nor conclusive, the results obtained so far allows evaluating our
proposal in a real-world case, concluding its validity.
Through all the research we have published several papers (see Section 7.4),
evaluating the different phases of our research.

189
7 CONCLUSION
Our research is a contribution to Enterprise Engineering area since we propose a
solution to the integration between Enterprise Architecture and IT Service
Management through the integration between TOGAF and ITIL. Considering these
two most important approaches in the Enterprise Engineering domain, we conducted
an overview of the research made relating these two frameworks.
We identified several benefits from the integration between TOGAF and ITIL
approaches, namely:
• Reducing duplication of efforts by avoiding parallel development initiatives;
• Integration of principles related to IT service lifecycle into EA approach;
• Creating synergies from ITIL and TOGAF thereby creating a greater impact
on results;
• Sharing of tools, language and methods;
• Increasing communication and collaboration;
• Sharing and exchanging information; and
• Developing and maintaining a consistent view of the same reality.
During the course of this research it became clear that the integration between
TOGAF and ITIL is a subject at its beginning. We found a small number of studies,
but none solved the problem in a satisfactory way.
Considering that both frameworks are complementary, but no integration proposal
answered the research questions, we have formulated and presented a proposal to
address the identified problem, aligning and integrating TOGAF and ITIL.
7.1 ANSWER TO RESEARCH QUESTIONS
From the identified benefits of integrating both approaches, we conclude that it makes
sense. We also identified many similarities between both approaches, clarifying that if
it would be rational to integrate TOGAF and ITIL in a single initiative, answering to
our research question number one “Does it make sense to integrate the two approaches?”.
The integration point between TOGAF and ITIL are the services delivered, which
are the organization’s reason for existence. This common focus enables an integrated
approach, maintaining the TOGAF principles with its own set of concepts, and
methods aligned with ITIL principles. This answers research question number two:
“How to integrate both approaches, which is the key path to integrate, and how can it be defined?”.

190
We realized that it would be harder to integrate two approaches if they did not share
the same concepts and “speak” the same language, so we needed a uniform
representation, a common frame of reference. Our intention was to find modelling
languages that best described each approach and map them according to similar
concepts. We found ArchiMate as the more convenient modelling language, already
used in TOGAF as the architecture modelling language, and so we also used
ArchiMate as the basis for integration representation.
It is not easy to share an organizational common understanding about all components
and architectures. The mapping and analysis between ITIL and ArchiMate is
challenging since concepts are specified in natural language and graphical
representation, but mapping in different models with formal semantics is complex.
That is, the human comprehensible description hardly has the same meaning to
different people, leading to different representation and interpretation of the concepts.
We address this problem by means of integration between ontologies of ITIL and
ArchiMate, as the adopted language to model TOGAF. We translated ITIL’s textual
descriptions to a graphical representation as an ITIL metamodel.
A conceptual map ensured the relevance of an ontology referential, clarifying the
mapping between concepts and diminishing the necessary efforts to deploy the
proposal’s solution.
We analysed the relationship among the concepts from ITIL and TOGAF identifying
a common ontology, allowing a formal representation of ITIL using ArchiMate.
Since the concepts and their mapping were defined, a common repository should be
used to store the organizational relationships. The integration encompassing the
relation between TOGAF and ITIL requires a shared and single repository.
Otherwise, IT is a collection of artifacts to meet technical requirements.
The single repository and the integration of both approaches, keeping the TOGAF
architectures, ITIL’s service lifecycle, and the metamodel for services, answered our
research question number three: “How to represent the integration between the two approaches
and, especially, their relationship?”.
The fourth question research “Considering the effort and magnitude needed to build and
maintain coherent information, how to keep the integrated information up-to-date and operationally
usable on a daily basis?” is answered by the share of information among functional
divisions, using ITIL processes to keep information updated.

191
ITIL principles and processes guarantee the update and consistency of information
with standard processes, such as configuration management and change management.
These processes ensure the reliability of data recorded and accessed in the common
repository, allowing us to see the changes' effects. The data repository was no longer a
mere database with CI and their relationships, nor an architectural artifacts map of
the “as-is” organizational state. Instead, in this approach it encompasses all TOGAF
principles in an operational way.
Having answered the research questions by providing a solution to the secondary
questions, we may conclude that our proposal was verified, making a contribution to
fill the lack in the research of integration between Enterprise Architecture and IT
Service Management, through the integration between TOGAF and ITIL.
The proposed integration captures the best practices from service management to
represent a semantic model so that an organization can understand and use ITIL
processes, and make business decision based on a holistic view of all organization.
7.2 MAIN CONTRIBUTIONS
A contribution arises from utility, namely by the answer to the fundamental questions:
“What utility does the new solution provide?” and “What demonstrates that utility?”
(Hevner et al., 2004).
The main goal of this dissertation is the integration of TOGAF and ITIL with a
respective representation. This contribution intends to be an academic reference, as a
basis for knowledge sharing and future work, but also an effective solution to the
identified problem.
In this dissertation we collected and developed a set of concepts defining an ontology
as the basis for integration work, establishing a formal specification of semantic
domain.
Once demonstrated their value and feasibility, our proposal may be used in
organizational practice, contributing to avoid duplication of efforts and resources,
allowing synergies between teams working in TOGAF and ITIL.
Our proposal was based on an ITIL metamodel, which did not exist, thus providing
an academic contribution in this area. Based on the ITIL metamodel, we also
provided a formal representation of ITIL, which is another contribution.

192
This dissertation also gave a contribution by validating ArchiMate as a modelling
language, enabling us to construct a model supported by a rigorous notation.
Another contribution was also achieved using this dissertation in the development of
tools supporting ITIL (EAMS was the obvious candidate).
One last contribution can be achieved if the use of this dissertation allows us to the use
of TOGAF on a day-to-day basis, avoiding the need of different frameworks.
We may synthetize our research contributions as the following:
• A clear identification of similarities between TOGAF and ITIL;
• A concept mapping of integration between concepts from TOGAF and ITIL;
• The use of ArchiMate to model ITIL;
• An ITIL metamodel, which is per se a valuable contribution, but we also
define an ArchiMate specialization to full representation;
• New ArchiMate viewpoints allowing the ITIL representation;
• A change management viewpoint as a model to manage the change in the
integration between both approaches; and
• A set of ArchiMate models for representing the ITIL’s process and functions.
7.3 LIMITATIONS
The integration between EA and ITSM was conducted through the integration
between TOGAF and ITIL while ArchiMate provided the modelling language that
allows the integration and the modelling.
However, ArchiMate was conceived to enterprise architecture scenarios in which a
formal modelling notation is required to address specific concerns related to formal
architecture modelling notation. The modelling of business processes with ArchiMate
does not have sufficient concepts in order to model with sufficient detail, namely
business rules, and decisions points.
This limitation prevents the use of our proposal in non-IT services and thus avoiding
the widespread of the proposal's application in other domains than IT.
The use of our proposal implies the need to learn ArchiMate modelling language.
Despite our initial proposal intends to integrate EA and ITSM, the use of ArchiMate
to achieve the integration between TOGAF and ITIL created a limitation to use our
proposal with other frameworks.

193
The validation of our proposal is still going on, and we are continuously improving.
Therefore, it is not conclusive and does not provide direct evidence whether our
proposal is also effective in other organizations.
Although we attempt to make the proposal generic enough to allow their applicability,
the proposal is still dependent on knowing the used frameworks and in particular the
ArchiMate modelling language.
7.4 PUBLICATIONS
This Section corresponds to the step “Communication” in the DSR Methodology,
where we communicate our work, providing clear contributions with some papers and
validating our proposal.
The results, and especially the proposed solution obtained through DSR, must be
presented both to technology-oriented (practitioners) as well as management-oriented
audiences (Hevner et al., 2004). So far, we have published the following 14 papers
related with this dissertation in international conferences and journals:
• Raul Silva, Nelson Gama, Miguel Mira da Silva, “Using People CMM for Dealing
with Resistance on Implementing ITIL”, 2010, Conference on Enterprise
Information Systems (CENTERIS 2010), ENTERprise Information Systems,
Communications in Computer and Information Science Volume 110, 2010,
pp. 259-263, Springer Berlin Heidelberg,
• Nelson Gama, Raul Silva, Miguel Mira da Silva, “Using People-CMM for
Diminishing Resistance to ITIL”, International Journal of Human Capital and
Information Technology Professionals – Vol 2 (3), 2011, IGI
• Nelson Gama, Miguel Mira da Silva, Rui Alves Francisco, “A Conceptual
Framework for Structuring an IT Organization”, 2011, 16th Annual Conference of
the UK Academy of Information Systems (UKAIS 2011), Oxford, England
(Rank C ERA)
• Nelson Gama, Lukasz Ostrowski & Miguel Mira da Silva, “Developing a
Conceptual Framework to Structure an IT Organization Using an Ontology Engineering
Methodology”, 2012, International Conference on e-Business (ICE-B 2012),
Rome, Italy. (Rank B ERA)
• Maria Mar Rosa, Nelson Gama, Miguel Mira da Silva, “A Method for Identifying
IT Services Using Incidents”. 2012, 8th IEEE International Conference on the

194
Quality of Information and Communications Technology (QUATIC 2012),
Lisbon, Portugal.
• Nelson Gama, Pedro Sousa, Miguel Mira da Silva, “Integrating Enterprise
Architecture and IT Service Management”, 2012, 21st International Conference on
Information Systems Development (ISD 2012), Prato, Italy. (Rank A ERA)
• Nelson Gama, Maria Mar Rosa, Miguel Mira da Silva, “IT Services Reference
Catalog”, 2013, IFIP/IEEE International Symposium on Integrated Network
Management, IM 2013 (Rank A ERA)
• Marco Vicente, Nelson Gama, Miguel Mira da Silva, “Modelling ITIL Business
Motivation Model in ArchiMate”, 2013, 4th International Conference on
Exploring Service Science 1.3 (IESS 2013), Porto, Portugal, LNBIP vol. 143.
p. 8699. Springer Berlin Heidelberg
• Marco Vicente, Nelson Gama, Miguel Mira da Silva, “Using ArchiMate and
TOGAF to Understand the Enterprise Architecture and ITIL Relationship”, 8th
International Workshop on Business/IT-Alignment and Interoperability, on
Business/IT-Alignment and Interoperability (BUSITAL), CAiSE 2013
Workshops, Valencia, Spain, June, 2013, vol. LNBIP. Springer Berlin
Heidelberg. (Rank A ERA)
• Lukas Ostrowski, Markus Helfert, Nelson Gama, “Ontology Engineering Step
in Design Science Research Methodology: A Technique to Gather and Reuse
Knowledge”, Behaviour & Information Technology Journal, 2013. Taylor and
Francis (Rank A ERA)
• Marco Vicente, Nelson Gama, Miguel Mira da Silva, “Using ArchiMate to
Represent ITIL Metamodel”. 15th IEEE Conference on Business Informatics (CBI
2013); Vienna, Austria; July, 2013.
• Marco Vicente, Nelson Gama, Miguel Mira da Silva, “The Value of ITIL in
Enterprise Architecture”, 17th IEEE International EDOC Conference; Vancouver,
Canada; September, 2013. (Rank B ERA)
• Marco Vicente, Nelson Gama, Miguel Mira da Silva, “A Business Motivation
Model for IT Service Management”, International Journal of Information System
Modelling and Design (IJISMD), January, 2014
• Nelson Gama, Marco Vicente, Miguel Mira da Silva, “ITIL Metamodel”, 12th
International Conference on Service Oriented Computing (ICSOC), 2014.
(Rank A ERA)

195
Additionally, we are writing the following papers:
• “Enterprise Architecture using ITIL Change Management” to be submitted to an
International Conference Rank A ERA
• “Enterprise Architecture and ITIL" to be submitted to the Enterprise Information
Systems Journal, Taylor & Francis
• “Integrating IT Service Management and Enterprise Architecture: Towards a TOGAF and
ITIL integration” to be submitted to the Information Systems Journal, Elsevier.
7.5 FUTURE WORK
We validated our proposal through scientific publications and also applied the
proposal in a organization. However, neither the field study has been concluded nor
the evaluation. The good results obtained so far should be measured and confirmed in
other type of organizations, and with other groups of practitioners.
The good results are merely qualitative. We should define attributes to quantify
measures associated with models, allowing a quantitative analysis of the proposed
approaches integration.
So far our integration point between both approaches were the services, which in this
case were merely IT oriented. However, ITIL best practices may be applied to
manage other kinds of services, for instance human resources, logistics, provisioning,
etc. Also TOGAF principles were born focused on IT, but can also be applied to any
kind of services. Therefore, this dissertation also wishes to raise awareness about using
the integration proposal in other domains.
We did not cover the ArchiMate extensions Motivation and Implementation and
Migration. These are two important extensions that have much in common with ITIL
and should be encompassed in the integration between TOGAF and ITIL.
Despite the subject and main goal of this dissertation is “Integrating Enterprise
Architecture and IT Service Management”, the realization was only focused on
TOGAF and ITIL. The followed integration method should be tested with other
frameworks.
The evaluation was basically analytic and a quantitative analysis should be developed
in the future, validating definitely the proposal.

196
Also the evaluation with the Moody and Shanks framework lacks on a less subjective
evaluation as was done.
Can become a valuable proposal if we demonstrate compliance with ITIL and other
standards for IT Service Management, such as ISO20000

197
REFERENCES
Abreu, F., Porciúncula, R., Freitas, J., & Costa, J. (2010). Definition and Validation of
Metrics for ITSM Process Models. Proceedings of the 7th International
Conference on the Quality of Information and Communications Technology
(QUATIC '10), 79-88. IEEE Computer Society
Addy, R. (2007). Effective IT Service Management: To ITIL and Beyond! London. Springer.
Aken, J. E. V. (2005). Management Research as a Design Science: Articulating the
Research Products of Mode 2 Knowledge Production in Management. British
Journal of Management, 16(1), 19-36. Wiley
Alturki, A., Gable, G., & Bandara, W. (2011). A Design Science Research Roadmap.
In H. Jain, A. Sinha & P. Vitharana (Eds.), Service-Oriented Perspectives in Design
Science Research (Vol. 6629, pp. 107-123): Springer Berlin / Heidelberg.
Alwadain, A., Fielt, E., Korthaus, A., & Rosemann, M. (2011). Where Do We Find
Services in Enterprise Architectures? A Comparative Approach. Proceedings of the
Australasian Conference on Information Systems (ACIS), (59).
Alwadain, A., Korthaus, A., Fielt, E., & Rosemann, M. (2010). Integrating SOA into an
Enterprise Architecture: A Comparative Analysis of Alternative Approaches. Proceedings of
the 5th IFIP Conference on Research and Practical Issues of Enterprise
Information Systems (CONFENIS), 1-15. Natal, Brazil.
Anderson, O. R. (2006). Some Interrelationships Between Constructivist Models of
Learning and Current Neurobiological Theory, With Implications for Science
Education. Journal of Research in Science Teaching, 29(10), 1037-1058. Wiley
Atkinson, C., & Kühne, T. (2003). Model-Driven Development: A Metamodeling
Foundation. IEEE Software, 20(5), 36 - 41. IEEE
Ayat, M., Sharifi, M., Sahibudin, S., & Ibrahim, S. (2009). Adoption Factors and
Implementation Steps of ITSM in the Target. Proceedings of the Third Asia
International Conference on Modelling & Simulation (AMS '09)(Issue), 369 -
374.Bali, Indonesia.
Baioco, G., Costa, A., Calvi, C., & Garcia, A. (2009). IT Service Management and
Governance Modeling an ITSM Configuration Process: A Foundational Ontology Approach.
Proceedings of the International Symposium on Integrated Network
Management-Workshops (IM '09) IFIP/IEEE, 24-33. New York.

198
Baskerville, R. (2008). What Design Science is Not. European Journal of Information
Systems(17), 441–443. Palgrave Macmilian
Bernard, S. A. (2005). An Introduction To Enterprise Architecture. Second Edition.
AuthorHouse.
Betz, C. T. (2003). The Convergence of Metadata and IT Service Management. University of
Minnesota. Retrieved from
http://erp4it.typepad.com/erp4it/uploads/MetadataITSM.pdf
Bharadwaj, A. S. (2000). A Resource-Based Perspective on Information Technology
Capability and Firm Performance: An Empirical Investigation. MIS Quarterly,
24(1), 169-196. Management Information Systems Research Center,
University of Minnesota
Bohmann, T., Junginger, M., & Krcmar, H. (2003). Modular Service Architectures: a
Concept and Method for Engineering IT Services. Proceedings of the 36th Annual
Hawaii International Conference on System Sciences. IEEE
Bon, J. v., Jong, A. d., Kolthof, A., Pieper, M., Tjassing, R., Veen, A. v. d., et al.
(2007). Foundations of IT Service Management Based on ITIL v3. Van Haren.
Braun, C., & Winter, R. (2005). A Comprehensive Enterprise Architecture
Metamodel and Its Implementation Using a Metamodelling Platform.
Enterprise Modelling and Information Systems Architectures (EMISA) (Vol. 75, pp. 64-
79).
Braun, C., & Winter, R. (2007). Integration of IT Service Management Into Enterprise
Architecture. Proceedings of the ACM Symposium on Applied Computing,
1215-1219. New York. Association for Computing Machinery
Brenner, M. (2006). Classifying ITIL Processes; A Taxonomy Under Tool Support Aspects.
Proceedings of the The First IEEE/IFIP International Workshop on Business-
Driven IT Management (BDIM '06), 19-28. Vancouver, BC, Canada. IEEE
Cabinet Office. (2011a). ITIL Lifecycle Suite 2011 Edition. Norwich. The Stationery
Office.
Cabinet Office. (2011b). ITIL: Service Strategy. Norwich, UK. The Stationery Office
(TSO).
Cabinet Office (Ed.). (2011c). ITIL: Continual Service Improvement. Norwich, UK. The
Stationery Office (TSO).

199
Cabinet Office (Ed.). (2011d). ITIL: Service Design. Norwich, UK. The Stationery
Office (TSO).
Cabinet Office (Ed.). (2011e). ITIL: Service Operation. Norwich, UK. The Stationery
Office (TSO).
Cabinet Office (Ed.). (2011f). ITIL: Service Transition. Norwich, UK. The Stationery
Office (TSO).
Calero, C., Ruiz, F., & Piattini, M. (2006). Ontologies for Software Engineering and Software
Technology. Springer.
Cameron, B. H., & McMillan, E. (2013). Analyzing the Current Trends in Enterprise
Architecture Frameworks. Journal of Enterprise Architecture, 9(1), 60-71.
Carr, N. G. (2003). IT Doesn't Matter. Harvard Business Review, 81(5), 41-49.
Cater-Steel, A., & Tan, W.-G. (2005). Implementation of IT Infrastructure Library (ITIL) in
Australia: Progress and Success Factors. Proceedings of the IT Governance
International Conference(Issue).Auckland, New Zealand.
Chen, H. (2008). Towards Service Engineering: Service Orientation and Business-IT Alignment.
Proceedings of the 41st Hawaii International Conference on System Sciences,
114--. Waikoloa, HI. IEEE Computer Society
Correia, A., & Abreu, F. B. e. (2009). Integrating IT Service Management Within the
Enterprise Architecture. Proceedings of the 4th International Conference on
Software Engineering Advances (ICSEA), 553 - 558. Porto, Portugal. IEEE
Curtis, B., Hefley, W. E., & Miller, S. A. (2001). The People Capability Maturity Model:
Guidelines for Improving the Workforce. Boston. Addison-Wesley.
Dietz, J. L. G. (2006). Enterprise Ontology: Theory and Methodology. Germany. Springer.
Dietz, J. L. G., Hoogervorst, J. A. P., Albani, A., Aveiro, D., Babkin, E., Barjis, J., et
al. (2013). The Discipline of Enterprise Engineering. International Journal of
Organisational Design and Engineering (IJODE), 3(1), 86-114. Inderscience
Edmondson, K. M. (2000). Assessing Science Understanding Through Concept
Maps. In A. Press (Ed.), Assessing science understanding (pp. 19-40). San Diego.
Eertink, H., Janssen, W., Luttighuis, P. O., Teeuw, W., & Vissers, C. (1999). A Business
Process Design Language. Proceedings of the 1st World Congress on Formal
Methods (FM’99), 1708, 76-95. Springer Berlin Heidelberg

200
Eriksson, H.-E., & Penker, M. (2000). Business Modeling with UML: Business Patterns at
Work. John Wiley and Sons.
Falbo, R. A. (2004). Experiences in Using a Method for Building Domain Ontologies.
Proceedings of the 16th International Conference on Software Engineering
and Knowledge Engineering (SEKE 2004), 474-477. Banff, Alberta, Canada.
Fettke, P., & Loos, P. (2003). Ontological Evaluation of Reference Models Using the Bunge-
Wand-Weber Model. Proceedings of the Americas Conference on Information
Systems (AMCIS), 384. Association for Information Systems
Forrester, E., Buteau, B., & Shrum, S. (Eds.). (2009). CMMI for Services: Guidelines for
Superior Service. Upper Saddle River, NJ. Addison-Wesley Professional.
Freitas, J. M., Correia, A., & Abreu, F. B. e. (2008). An Ontology for IT Services.
Proceedings of the Conference on Software Engineering and Databases
(JISBD'08), 367-372.
Gama, N., Mira da Silva, M., Caetano, A., & Tribolet, J. (2007). Integrar a Arquitectura
Organizacional na Arquitectura Empresarial. Proceedings of the Conferência da
Associação Portuguesa de Sistemas de Informação (CAPSI 2006). Aveiro. 7ª
Conferência da Associação Portuguesa de Sistemas de Informação
Gama, N., Mira da Silva, M., & Francisco, R. A. (2011). A Conceptual Framework for
Structuring an IT Organisation. Proceedings of the 16th Annual Conference of the
UKAIS. Oxford, England.
Gama, N., Rosa, M., & Mira da Silva, M. (2013). IT Services Reference Catalog.
Proceedings of the IFIP/IEEE International Symposium on Integrated
Network Management (IM 2013). Ghent, Belgium. IEEE
Gama, N., Silva, R., & Mira da Silva, M. (2011). Using People-CMM for Diminishing
Resistance to ITIL. International Journal of Human Capital and Information
Technology Professionals (IJHCITP), 2(3), 29-43.
Gama, N., Sousa, P., & Mira da Silva, M. (2012). Integrating Enterprise Architecture and IT
Service Management. Proceedings of the 21st International Conference on
Information Systems Development (ISD 2012). Prato, Italy. Springer
Garschhammer, M., Hauck, R., Kempter, B., Radisic, I., Roelle, H., & Schmidt, H.
(2001). The MNM Service Model - Refined Views on Generic Service
Management. Journal of Communications and Networks, 3(4).
Gill, J., & Johnson, P. (1991). Research Methods. London. Sage.

201
Greefhorst, D., & Proper, E. (2011). Architecture Principles: The Cornerstones of Enterprise
Architecturex. Springer.
Gruber, T. R. (1995). Toward Principles for the Design of Ontologies Used for
Knowledge Sharing. International Journal of Human-Computer Studies, 43(5-6), 907-
928. Sciencedirect. Elsevier
Grüninger, M., Atefi, K., & Fox, M. S. (2000). Ontologies to Support Process
Integration in Enterprise Engineering. Computational & Mathematical Organization
Theory, 6(4), 381-394. Association for Computing Machinery
Guizzardi, G. (2007). On Ontology, Ontologies, Conceptualizations, Modeling
Languages. In J. E. O. Vasilecas, & A. Caplinskas (Eds.) (Ed.), Frontiers in
Artificial Intelligence and Applications, Databases and Information Systems IV (Vol. 15,
pp. 18-39): Amsterdã: IOS Press.
Haki, M. K., & Forte, M. W. (2010). Service-Oriented Business-IT Alignment: a SOA
Governance Model. AISS: Advances in Information Sciences and Service Sciences, 2(2),
51-60. Bibsonomy
Heiskala, M., Tiihonen, J., & Soininen, T. (2005). A Conceptual Model for Modeling
Configurable Services from a Customer Perspective. Proceedings of the Configuration
Workshop at IJCAI'05. Edinburgh, Scotland.
Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in
Information Systems Research. MIS Quarterly, 28(1), 75-105. Springer
Hines, T. (2000). An Evaluation of Two Qualitative Methods (Focus Group
Interviews and Cognitive Maps) for Conducting Research into
Entrepreneurial Decision Making. Qualitative Market Research, 3(1), 7-16.
Emerald
Hochstein, A., Zarnekow, R., & Brenner, W. (2005). ITIL as Common Practice Reference
Model for IT Service Management: Formal Assessment and Implications for Practice.
Proceedings of the International Conference on e-Technology, e-Commerce
and e-Service (EEE '05), 704-710. IEEE Computer Society
Hoogervorst, J. (2004). Enterprise Architecture: Enabling Integration, Agility and
Change. International Journal of Cooperative Information Systems, 13(3), 213-233.
World Scientific

202
Huang, X., Shen, B., & Chen, D. (2010). IT Service Support Process Meta-Modeling Based
on ITIL. Proceedings of the 2010 International Conference Data Storage and
Data Engineering (DSDE), 127 - 131. Bangalore.
Iacob, M.-E., Quartel, D., & Jonkers, H. (2012). Capturing Business Strategy and Value in
Enterprise Architecture to Support Portfolio Valuation. Proceedings of the 16th
Enterprise Distributed Object Computing Conference (EDOC), IEEE, 11 -
20. Beijing, China. IEEE
IBM Corporation. (1981). A Management System for the Information Business.
Management Overview, Volume 1. White Plains, NY
IEEE Computer Society. (2011). ISO/IEC/IEEE 42010: Systems and Software
Engineering — Architecture Description. IEEE Computer Society.
Iivari, J., & Venable, J. R. (2009). Action Research and Design Science Research – Seemingly
Similar but Decisively Dissimilar. Proceedings of the 17th European Conference
on Information Systems, 1642 - 1653. Verona, Italy.
ISACA. (2011). Control OBjectives for IT - COBIT 4.1. ISACA.
Jantti, M., & Eerola, A. (2006). A Conceptual Model of IT Service Problem Management.
Proceedings of the International Conference on Service Systems and Service
Management (ISSSM 2006), 1, 798-803. Troyes, France.
Johnson, M. W., Hately, A., Miller, B. A., & Orr, R. (2007). Evolving Standards for
IT Service Management. IBM Systems Journal, 46(3), 583 - 597. Association for
Computing Machinery
Jonkers, H., Proper, E., & Turner, M. (2009). TOGAF™ and ArchiMate®: A Future
Together. The Open Group. Van Haren Publishing.
Jung, C.-k. (2009). Actionable Enterprise Architecture. Proceedings of the 10th ACIS
International Conference on Software Engineering, Artificial Intelligences,
Networking and Parallel/Distributed Computing, 294-299. Association for
Computing Machinery
Kashanchi, R., & Toland, J. (2006). Can ITIL Contribute to IT/Business Alignment?
An Initial Investigation. Wirtschaftsinformatik, 48(5), 340-348. Springer
Kieninger, A., Baltadzhiev, D., Schmitz, B., & Satzger, G. (2011). Towards Service Level
Engineering for IT Services: Defining IT Services from a Line of Business Perspective.
Proceedings of the SRII Global Conference (SRII 2011) 759 - 766. San Jose,
CA. IEEE

203
Kistasamy, C., Merwe, A. V. d., & Harpe, A. D. L. The Relationship Between Service
Oriented Architecture and Enterprise Architecture. Proceedings of the Enterprise
Distributed Object Computing Conference Workshops (EDOCW), 14th IEEE
International, 129 – 137. Vitoria. IEEE
Klecun, E., & Cornford, T. (2005). A Critical Approach to Evaluation. European
Journal of Information Systems, 14(3), 229–243. LSE
Ko, R. K. L. (2009). A Computer Scientist's Introductory Guide to Business Process
Management (BPM). Crossroads, 15(4), 11-18. Association for Computing
Machinery
Lahtela, A., Jantti, M., & Kaukola, J. (2010). Implementing an ITIL-Based IT Service
Management Measurement System. Proceedings of the ICDS '10. Fourth
International Conference, 249 - 254. St. Maarten. IEEE
Lankhorst, M. (2009). Enterprise Architecture at Work (2nd Ed.). Springer.
Lankhorst, M., Buuren, R., Leeuwen, D., & Jonkers, H. (2004). Enterprise
Architecture Modelling-the Issue of Integration. Advanced Engineering Informatics,
18(4), 205-216.
Lankhorst, M., & Drunen, H. v. (2007). Enterprise Architecture Development and
Modelling. from http://www.via-nova-architectura.org
Lea-Cox, T. (2013a). Enterprise Architecture and ITIL: Implementing Service Design
(Vol. July). White Paper. Orbus Software.
Lea-Cox, T. (2013b). Enterprise Architecture and ITIL: Implementing Service
Strategy (Vol. April). White Paper. Orbus Software.
Lea-Cox, T. (2013c). Enterprise Architecture and ITIL: Implementing Service
Transition of Work. In
Lea-Cox, T. (2013d). Enterprise Architecture and ITIL: Where is the Value in ITIL?
of Work. In
Liles, D. H., & Presley, A. R. (1996). Enterprise Modeling Within An Enterprise Engineering
Framework. Proceedings of the 28th Conference on Winter Simulation (WSC
'96), 993 - 999. Coronado, California, United States. Association for
Computing Machinery (ACM)

204
Maes, R., Rijsenbrij, D., Truijens, O., & Goedvolk, H. (2000). Redefining Business – IT
Alignment Through a Unified Framework. Proceedings of the Landelijk Architectuur
Congres(Issue).Amsterdam. PrimaVera Working Paper Series
March, S. T., & Smith, G. F. (1995). Design and Natural Science Research on
Information Technology. Decision Support Systems, 15(4), 251-266.
ScienceDirect. Elsevier
Marshall, C. (2000). Enterprise Modeling with UML: Designing Successful Software through
Business Analysis. Addison Wesley Longman.
Martin, J. (1995). The Great Transition: Using the Seven Disciplines of Enterprise Engineering to
Align People, Technology, and Strategy. AMACOM.
Mayer, R. J., Crump, J. W., Fernandes, R., Keen, A., & Painter, M. K. (1995).
Information Integration for Concurrent Engineering (IICE) Compendium of
Methods Report of Work. In W.-P. A. F. Base.
Meertens, L. O., Iacob, M. E., Nieuwenhuis, L. J. M., Sinderen, M. J. v., Jonkers, H.,
& Quartel, D. (2012). Mapping the Business Model Canvas to ArchiMate.
Proceedings of the 27th Annual ACM Symposium on Applied Computing
(SAC '12), 1694-1701. New York, NY, USA. ACM
Mendes, C., & Mira da Silva, M. (2010). Implementing the Service Catalogue Management.
Proceedings of the 7th International Conference on the Quality of Information
and Communications Technology (QUATIC), 159-164. Porto, Portugal.
IEEE Computer Society
Miller, G. A. (1956). The Magical Number Seven, Plus or Minus Two: Some Limits
on Our Capacity for Processing Information. Psychological Review, 63(2), 81-97.
Mintzes, J. J., Wandersee, J. H., & Novak, J. D. (2000). Assessing Science Understanding: A
Human Constructivist View. San Diego.
Moody, D. L., & Shanks, G. G. (2003). Improving the Quality of Data Models:
Empirical Validation of a Quality Management Framework. Journal of
Information Systems, 28, 619–650. Elsevier
Moody, D. L., Sindre, G., Brasethvik, T., & Solvberg, A. (2003). Evaluating the Quality
of Information Models: Empirical Testing of a Conceptual Model Quality Framework.
Proceedings of the 25th International Conference on Software Engineering,
295-305. Washington, DC, USA. IEEE Computer Society

205
Moser, C., & Bayer, F. (2005). IT Architecture Management: A Framework for IT-Services.
Proceedings of the Workshop in Enterprise Modelling and Information
Systems Architectures. Klagenfurt.
Nabiollahi, A., Alias, R. A., & Sahibuddin, S. (2010). A Service Based Framework for
Integration of ITIL V3 and Enterprise Architecture. Proceedings of the 2010
International Symposium in Information Technology (ITSim), 1, 1-5. Kuala
Lumpur. IEEE
Nabiollahi, A., & Sahibuddin, S. b. (2008). Considering Service Strategy in ITIL V3 as a
Framework for IT Governance. Proceedings of the International Symposium on
Information Technology (ITSim 2008) 1, 1-6. Kuala Lumpur, Malaysia. IEEE
Nadler, D., Gerstein, M. C., & Shaw, R. B. (1992). Organizational Architecture. San
Francisco. Jossey-Bass.
Nakakawa, A. (2008). Collaboration Engineering Approach to Enterprise Architecture Design
Evaluation and Selection. Proceedings of the CAiSE 2008, 343, 85-94.
Montpellier, France. CEUR-WS
Neto, A. N. F., & Neto, J. S. (2011). Metamodels of Information Technology Best
Practices Frameworks. Journal of Information Systems and Technology Management
(JISTEM), 8(3), 619-640.
Nicewicz-Modrzewska, D., & Stolarski, P. (2008). ITIL Implementation Roadmap Based on
Process Governance. Proceedings of the European University Information Systems
(EUNIS 2008).
Noran, O., & Bernus, P. (2008). Service Oriented Architecture vs. Enterprise
Architecture: Competition or Synergy? Lecture Notes in Computer Science, 5333,
304-312. Springer
Novak, J. D. (1990). Concept Maps and Vee Diagrams: Two Metacognitive Tools for
Science and Mathematics Education. Instructional Science, 19(1), 29-52. Springer
Novak, J. D., & Cañas, A. J. (2008). The Theory Underlying Concept Maps and How
to Construct and Use Them. Florida. Technical Report IHMC CmapTools.
OASIS. (2006). Reference Model for Service Oriented Architecture 1.0 Committee
Specification 12 October 2006.
Oates, B. J. (2006). Researching Information Systems and Computing. Sage Publications.

206
Object Management Group. (2011). Business Process Model and Notation (BPMN)
Version 2.0.
OGC. (2007). ITIL Glossary of Terms, Definitions and Acronyms of Work. v3.1.24.
In
Okoli, C., & Schabram, K. (2010). A Guide to Conducting a Systematic Literature Review of
Information Systems Research. Working Papers on Information Systems. Sprouts.
Retrieved from http://ssrn.com/abstract=1954824
OMG. (2003a). Business Process Definition Metamodel (BPDM) OMG Adopted
Specification. The Object Management Group (OMG).
OMG. (2003b). MDA Guide Version 1.0. The Object Management Group (OMG).
Open Group. (2009). SOA Reference Architecture (v.10).
Open Group. (2011). The Open Group Architecture Framework (TOGAF) Version
9.1.
Open Group. (2012). ArchiMate 2.0 Specification. Van Haren Publishing.
Ostroff, C., & Schmitt, N. (1993). Configurations of Organizational Effectiveness and
Efficiency. The Academy of Management Journal, 36(6), 1345-1361. Academy of
Management
Ostrowski, L. (2011). Detailed Design Science Research and its Impact on the Quality of Design
Artefact. Proceedings of the Intel European Research and Innovation
Conference (ERIC). Leixlip. Springer
Ostrowski, L., Helfert, M., & Xie, S. (2012). A Conceptual Framework to Construct an
Artefact for Meta-Abstract Design. Proceedings of the 45th Hawaii International
Conference on System Sciences (HICSS), 4074-4081. Maui, Hawaii. IEEE
Papazoglou, M. P., Traverso, P., Dustdar, S., & Leymann, F. (2007). Service-Oriented
Computing: State of the Art and Research Challenges. Journal Computer Archive,
40(11), 38-45. IEEE Computer Society Press Los Alamitos, CA, USA
Parreiras, F. S., Pan, J. Z., Assmann, U., & Henriksson, J. (2009). First Workshop on
Transforming and Weaving Ontologies in Model Driven Engineering Lecture
Notes in Computer Science, 5421, 314-317. Springer
Peffers, K., Tuunanen, T., Rothenberger, M., & Chatterjee, S. (2007). A Design
Science Research Methodology for Information Systems Research. Journal of
Management Information Systems, 24(3). Association for Computing Machinery

207
Pereira, C., & Sousa, P. (2004). A Method to Define an Enterprise Architecture Using the
Zachman Framework. Proceedings of the 19th Annual ACM Symposium on
Applied Computing (SAC'04), 1366-1371. Nicosia, Cyprus. Association for
Computing Machinery
Pereira, C., & Sousa, P. (2005). Enterprise Architecture: Business and IT Alignment.
Proceedings of the 20th ACM Symposium on Applied Computing (SAC
'05)(Issue).Santa Fe, USA. ACM
Pereira, R., & Mira da Silva, M. (2012). Towards an Integrated IT Governance and IT
Management Framework. Proceedings of the 16th International Enterprise
Distributed Object Computing Conference (EDOC 2012). Beijing, China.
IEEE
Peyret, H. (2011a). Business Service Architecture: Shaping The Services Within Your
Business Model. Forrester.
Peyret, H. (2011b). Integrate EA With ITIL Service Portfolio Management. Forrester.
Pries-Heje, J., Baskerville, R., & Venable, J. R. (2008). Strategies for Design Science
Research Evaluation. Proceedings of the 16th European Conference on
Information Systems (ECIS). Ireland. National University of Ireland
Radhakrishnan, R. (2008). Enterprise Architecture & IT Service Management Making
Standards Work. The Open Group.
Roepke, R., Agarwal, R., & Ferratt, T. W. (2000). Aligning the IT Human Resource
with Business Vision: Leadership Initiative at 3M. MIS Quarterly, 24(2), 327-
353.
Rohloff, M. (2008). An Integrated View on Business- and IT-Architecture. Proceedings of the
2008 ACM Symposium on Applied Computing (SAC '08), 561-565. Fortaleza,
Ceará, Brazil. Association for Computing Machinery
Rosa, M., Gama, N., & Mira da Silva, M. (2012). A Method for Identifying IT Services
Using Incidents. Proceedings of the 8th International Conference on the Quality
of Information and Communications Technology (QUATIC 12). Lisbon,
Portugal. IEEE
Ross, J. W., Weill, P., & Robertson, D. C. (Eds.). (2006). Enterprise Architecture As
Strategy: Creating a Foundation for Business Execution. Boston. Harvard Business
Scholl Press.

208
Sante, T. v., & Ermers, J. (2009). TOGAF 9 and ITIL V3 Two Frameworks Whitepaper.
Best Management Practice. OGC.
Scheer, A.-W. (1994). Business Process Engineering: Reference Models for Industrial Enterprises
(2 Ed.). Berlin. Springer.
Scheer, A.-W. (1999). ARIS - Business Process Frameworks. Springer.
Schekkerman, J. (2006). The Economic Benefits of Enterprise Architecture: How to Quantify and
Manage the Economic Value of Enterprise Architecture. Canada. Trafford Publishing.
Schekkerman, J. (Ed.). (2004). How to Survive in the Jungle of Enterprise Architecture
Frameworks. Victoria, Canada. Trafford Publishing.
Schuette, R., & Rotthowe, T. (1998). The Guidelines of Modeling – An Approach to
Enhance the Quality in Information Models. Lecture Notes In Computer Science
(LNCS), 1507, 240-254. Springer
Sein, M. K., Henfridsson, O., Purao, S., Rossi, M., & Lindgren, R. (2011). Action
Design Research. MIS Quarterly, 35(1), 37-56.
Sessions, R. (2007). A Comparison of the Top Four Enterprise-Architecture Methodologies.
MSDN Library. ObjectWatch, Inc.
Shanks, G., Tansley, E., & Weber, R. (2003). Using Ontology to Validate Conceptual
Models. ACM New York, 46(10), 85-89. Association for Computing Machinery
Sharifi, M., Ayat, M., Rahman, A., & Sahibudin, S. (2008). Lessons Learned in ITIL
Implementation Failure. Proceedings of the International Symposium on
Information Technology (ITSim 2008), 2, 1-4. Kuala Lumpur, Malaysia.
IEEE
Shen, B., Huang, X., Zhou, K., & Tang, W. (2010). Engineering Adaptive IT Service
Support Processes Using Meta-modeling Technologies. Lecture Notes In Computer
Science (LNCS), 6195, 200-210. Springer
Skinner, D., Tagg, C., & Holloway, J. (2000). Managers and Research: The Pros and
Cons of Qualitative Approaches. Management Learning, 31(2), 163-179.
Society for Information Management. (2010). IT Industry Trend Survey of Work. In
Söderström, E., Andersson, B., Johannesson, P., Perjons, E., & Wangler, B. (2001).
Towards a Framework for Comparing Process Modelling Languages. Lecture
Notes In Computer Science (LNCS), 2348 (14th International Conference on
Advanced Information Systems Engineering), 600 – 611. Springer

209
Sousa, P., Caetano, A., Vasconcelos, A., Pereira, C., & Tribolet, J. (2006). Enterprise
Architecture Modelling with the Unified Modelling Language 2.0 Enterprise
Modelling and Computing with UML. Hershey: IRM Press.
Sousa, P., Gabriel, R., Tadao, G., Carvalho, R., Sousa, P. M., & Sampaio, A. (2011).
Enterprise Transformation: The Serasa Experian Case. Lecture Notes in Business
Information Processing, 89, 134-145. springer
Sousa, P., Lima, J., Sampaio, A., & Pereira, C. (2009). An Approach for Creating and
Managing Enterprise Blueprints: A Case for IT Blueprints. Lecture Notes in
Business Information Processing, 34, 70-84. Springer
Sousa, P., Martins, R., & Sampaio, A. (2012). A Clarification of the Application
Concept: The Caixa Geral de Depósitos Case. Lecture Notes in Business
Information Processing, 120, 1-17. Springer
Spewak, S., & Hill, S. (Eds.). (1992). Enterprise Architecture Planning: Developing a Blueprint
for Data, Applications and Technology. Wiley.
Strahonja, V. (2009). Definition Metamodel of ITIL. Information Systems Development,
Challenges in Practice, Theory, and Education Volume 2, 1081-1092. Springer
Strauss, A., & Corbin, J. M. (1990). Basics of Qualitative Research: Grounded Theory
Procedures and Techniques. Thousand Oaks, CA, US: Sage Publications, Inc.
Thorn, S. (2007). TOGAF and ITIL (p. 26). San Francisco. The Open Group.
Tiwana, A., & Konsynski, B. (2010). Complementarities Between Organizational IT
Architecture and Governance Structure. Information Systems Research, 21(2), 288-
304.
Tsai, W.-T., Chen, Y., & Fan, C. (2006). PESOI: Process Embedded Service-
Oriented Architecture. Journal of Software, 17(6), 1470−1484.
Vaishnavi, V. K., & Kuechler, W. (2007). Design Science Research Methods and Patterns:
Innovating Information and Communication Technology. Boston, MA, USA. Auerbach
Publications.
Valiente, M.-C., Garcia-Barriocanal, E., & Sicilia, M.-A. (2012). Applying an
Ontology Approach to IT Service Management for Business-IT Integration.
Knowledge-Based Systems, 28(April), 76–87. ScienceDirect. Elsevier
Vasconcelos, A., Caetano, A., Neves, J., Sinogas, P., Mendes, R., & Tribolet, J.
(2001). A Framework for Modeling Strategy, Business Processes and Information Systems.

210
Proceedings of the Fifth IEEE International Enterprise Distributed Object
Computing Conference (EDOC 2001)(Issue), 69-81.Seattle, Washington.
IEEE Computer Society
Vasconcelos, A., Mira da Silva, M., Fernandes, A., & Tribolet, J. (2004). An Information
System Architectural Framework for Enterprise Application Integration. Proceedings of
the Organizational Systems and Technology Track of the Thirty Seventh
Hawaii Conference on Sistem Sciences (HICSS-37), 8(Issue), 9.Havaii. IEEE
Computer Society
Vasconcelos, A., Sousa, P., & Tribolet, J. (2003). Information System Architectures:
Representation, Planning and Evaluation. Journal of Systemics, Cybernetics and
Informatics, 1(6).
Vasconcelos, A., Sousa, P., & Tribolet, J. (2007). Information System Architecture
Metrics: an Enterprise Engineering Evaluation Approach. Electronic Journal of
Information Systems Evaluation, 10(1), 91-122.
Venable, J. R. (2006). A Framework for Design Science Research Activities. Proceedings of the
Information Resources Management Association International Conference,
184-187. Washington, DC, USA.
Venkatraman, N. (1994). IT-Enabled Business Transformation: From Automation to
Business Scope Redefinition. Sloan Management Review, 35(2), 73.
ABI/INFORM Global
Vicente, M., Gama, N., & Mira da Silva, M. (2013a). Using ArchiMate and TOGAF to
Understand the Enterprise Architecture and ITIL Relationship. Proceedings of the 8th
International Workshop on Business/IT-Alignment and Interoperability,
CAiSE 2013 Workshops, 148, 134–145. Springer Berlin Heidelberg
Vicente, M., Gama, N., & Mira da Silva, M. (2013b). Using ArchiMate to Represent ITIL
Metamodel. Proceedings of the 15th IEEE Conference on Business Informatics
(CBI). IEEE
Vieira, A., Costa, L., Amaro, P., Amorim, L., Pina, M., Pereira, C., et al. (2004).
Arquitectura Empresarial e Sistemas de Gestão da Qualidade. Proceedings of the
International Conference on the Quality of Information and Communications
Technology (QUATIC '04). Porto, Portugal.
Vorisek, J., & Jandos, J. (2010). Enterprise Computing Management Based on ICT Services.
Proceedings of the Euro-American Association on Telematics and Information
Systems (EATIS). Panama.

211
Wand, Y., & Weber, R. (1993). On the Ontological Expressiveness of Information
Systems Analysis and Design Grammars. Information Systems Journal, 3(4), 217–
237. Wiley
Weill, P., & Ross, J. (Eds.). (2004). IT Governance: How Top Performers Manage IT Decision
Rights for Superior Results. Harvard Business School Press
Weiss, J. W., & Anderson, D. (2004). Aligning Technology and Business Strategy: Issues &
Frameworks, A Field Study of 15 Companies. Proceedings of the 37th Annual
Hawaii International Conference on System Sciences (HICSS'04), 8(8).
Hawaii. IEEE Computer Society Washington, DC, USA
Winter, R. (2008). Design Science Research in Europe. European Journal of Information
Systems, 17, 470–475. Springer
Winter, R., & Fischer, R. (2007). Essential Layers, Artifacts, and Dependencies of
Enterprise Architecture. Journal of Enterprise Architecture, 3(2), 7-18. IEEE
Wout, J. V. t., Waage, M., Hartman, H., Stahlecker, M., & Hofman, A. (2010). The
Integrated Architecture Framework Explained: Why, What, How. Springer.
Yang, Y., & Padmanabhan, B. (2005). Evaluation of Online Personalization Systems:
A Survey of Evaluation Schemes and A Knowledge-Based Approach. Journal of
Electronic Commerce Research, 6(2), 112-122.
Zacarias, M., Pinto, H. S., Magalhães, R., & Tribolet, J. (2010). A ‘Context-Aware’
and Agent-Centric Perspective for the Alignment Between Individuals and
Organizations. Information Systems, 35(4), 441-466. ScienceDirect. Elsevier
Zacarias, M., Pinto, H. S., & Tribolet, J. (2007). Integrating Engineering, Cognitive
and Social Approaches for a Comprehensive Modeling of Organizational
Agents and Their Contexts. Lecture Notes in Computer Science, 4635, 517-530.
Springer
Zachman, J. (1987). A Framework for Information Systems Architecture. IBM Systems
Journal, 26(3), 276-292.
Zachman, J. (1997). Enterprise Architecture: The Issue of the Century. Database
Programming and Design, March, 1-13.

A-1
Appendix A – ARCHITECTURE MODELLING LANGUAGES
EA have different domains all of them should be represented to express the
organization’s dimensions, the relationship between domains and as a communication
tool between stakeholders.
However in different domains such as business processes, applications, information
and infrastructure we have different representation and description languages for
modelling business and IT. In this section we describe some languages with a
widespread use in developing an EA.
Business Process Modelling
Business process models represent the essence of the organization encompassing
different levels of organizational detail (Eertink et al., 1999).
To be useful, serving as a mean of communication between people involved real
models have to combine different requirements, simultaneously easily accessible and
highly understandable.
A model in this context is an abstract and unambiguous conception of the real world
that focuses on specific aspects or elements and abstracts from other elements, based
on the purpose for which the model is created. In this context, models are typically
represented using a formalized graphical or textual language (Lankhorst, 2009).
Often people discussing models are not especially trained in using modelling
languages. However, they have to discuss the results with other stakeholders, namely
management and operational people. Therefore, the representation should be
graphical and based on concepts that are relevant to the domain of interest, with a
clear architectural meaning in modelling (Eertink et al., 1999).
Models should be analysable using tools and serve as a starting point for system
design. Therefore, models should have a rigorously defined meaning and syntax, as a
standard language.
The Business Process Modelling Notation (BPMN) is a graphical representation for
specifying business processes in a business process model as illustrated with Figure 96
(Object Management Group, 2011).
BPMN is a standard developed by the Business Process Management Initiative
(BPMI) and now maintained by the Object Management Group, since the two
organizations merged in 2005.

A-2
The BPMN standard, which current version is the BPMN 2.0, specifies a graphical
notation that serves as business process modelling language. The main purpose of
BPMN is to provide a uniform notation for modelling business processes in terms of
activities and their relationships.
As the name already indicates, BPMN only defines a concrete syntax, i.e., a uniform
(graphical) notation for business process modelling concepts in Business Process
Diagrams (BPD), based on flowcharts very similar to activity diagrams from Unified
Modelling Language (UML). However, BPMN is limited to the business processes
dimension, all other dimensions or views, like applications or infrastructure, are not
covered by the language. Its main purpose is to provide a uniform notation in terms of
activities and relationships.
In fact, BPMN’s scope is limited to business processes and it does not provide concepts
for modelling e.g. organisational structures, data models, or the relation between
business activities and supporting IT applications, making it of limited use in
enterprise architecture (Lankhorst et al., 2004)
Figure 96 – BPMN elements
BPMN’s lanes, in its simpler forms, model roles but when processes are performed by
multiple roles, collaboration can be hard to represent. Additionally, and from an
informational point of view, although there is data objects representations, there is no
distinction between a business object (as a conceptual entity), its realization in the real
world and its representation as a data object. On the other hand, different
stakeholders have different views of the world.

A-3
A single model does not represent everyone’s needs or interpretation of the world and
it is dependent from the viewer observation around him or her (Lankhorst, 2009).
Modelling with DEMO avoid some of misinterpretations (Dietz, 2006), however with
a loss in communication capabilities between stakeholders.
IDEF
IDEF stands for Integration Definition1 (Mayer et al., 1995), and is a language used to
modelling and analysis in the field of systems and software engineering. The IDEF
was developed with a military background for Integrated Computer Aided
Manufacturing (ICAM) and still most commonly used by Department of Defence
(DoD) agencies, as well as other public domain.
Figure 97 – Examples of IDEF Models
1 http://www.idef.com

A-4
Nowadays, there are 16 IDEF methods covering a wide range of uses in enterprise
modelling, from functional modelling to data, simulation, object-oriented
analysis/design and knowledge acquisition. Some are illustrated in Figure 97.
Of these methods, the most-widely recognized and used components of the IDEF
family are IDEF0, a functional modelling language building on Structured Analysis
and Design Technique (SADT), IDEF3 that captures the workflow of business
processes through flow diagrams, and IDEF1X, which addresses information models
and database design issues.
Despite IDEF family provides support for modelling of several architectures views,
there are no communication mechanisms between models. Actually, once they are
isolated hinders the visualization of all models as interrelated elements of an
architectural system. This means that a switch between views is not possible
(Lankhorst, 2009) and the relations between domains are not clearly defined
(Lankhorst et al., 2004).
ARIS
The Architecture of Integrated Information System is a systematic approach,
supported by ARIS software tool to enterprise modelling (Scheer, 1999).
ARIS started as an academic research (Scheer, 1994) and currently has a strong
industrial background, becoming widespread despite it is not a standard.
This methodology allows different visualizations for different purposes. Moreover, it
offers methods for analysing processes and taking a holistic view of process design,
management, workflow, and application processing. Therefore, the ARIS approach
not only provides a generic and well-documented methodological framework but also
a powerful business process modelling tool, providing a repository serving as an
organizational memory (Eertink et al., 1999). The tool is intended for system
designers, however, analysis is limited.
In ARIS, event-process chain diagrams describe business processes. The modelling is
done using a tool set instead of a language. Several sub-tools are available, each
displayed in its own window. The information captured by the ARIS tool set is stored
in a database following the ERM (Entity-Relationship-Model). In Scheer (Scheer,
1999) it is argued that a formal language imposes restrictions on the day-to-day
usability by potential end users. On the other hand, the graphical notation of ARIS is
unambiguous, but rather extensive, with quite a learning curve (Lankhorst, 2009).
Also the tool is complex to use, has relatively long learning curve, and does not handle
multiple languages well.

A-5
Figure 98 shows the model of ARIS architecture but is not presented the main
concepts used as graphical notation like events, functions, control flows, logical
operators, organizational units, interactions, outputs, data and information, goals,
applications and infrastructure hardware.
While ARIS allows for various perspectives (Figure 98) on the organization
(organization view, data view, function view, control view, and resource view), the
integration of these aspects is somewhat lacking and dos not guarantee the overall
integrity of interrelated models. There is a formal definition of syntax of event-driven
process chain, but they lack a precise definition of their semantics. The semantics of
event-driven process chains are given roughly in verbal form (Lankhorst, 2009). On
the other hand, the languages are proprietary to a specific software tool and the
relations between domains are not clearly defined (Lankhorst et al., 2004).
Figure 98 – Model of the ARIS architecture
UML
The UML (Unified Modelling Language) is widespread standardized general-purpose
modelling language in the field of object-oriented software engineering, providing
specification, visualization, construction, and documentation from the artefacts of
software systems.

A-6
The language emerged from the combination of older notations and currently is
developed, and managed by the Object Management Group (OMG).
UML involves a set of concepts and language elements for different uses and diagrams
such as activities, use-case, actors, state, business processes, class, objects, behaviours,
software components, etc. The language combines techniques from data modelling
(entity relationship diagrams), business modelling (work flows), object modelling, and
component modelling. It can be used with all processes, throughout the software
development life cycle, and across different implementation technologies (Marshall,
2000)
Besides the approach was developed for software development and to be used by
system designers. The object-oriented principles allow UML to a widespread use in
different architecture domains with a set of graphic notation techniques to specify,
create, visualize and document system's architectural views, including visual models.
In contrast to organization and business process modelling, for which there is no single
dominant language, in modelling applications and technology UML has become a
true world standard. This important language is used for modelling software systems,
but also for business processes and for the general business architecture.
UML have a rich combination of 13 sublanguages, as illustrated with Figure 99, each
having its own scope, and each with is own diagram to model a specific aspect of a
system. Each diagram type describes a system or parts from a defined point of view,
and contains its own symbols.
However, despite the diagram types and UML meta-model are interrelated no strict
separation between views has been made, and special visualisations and views of UML
models should be provided (Lankhorst et al., 2004). On the other hand, UML is not
readily accessible and understandable for managers and business consultants, and
other modelling languages will likely provide an interface or mapping to it (Lankhorst,
2009). Another important weakness of the UML is the large number of diagram types,
with poorly defined relations between them (Lankhorst et al., 2004).
UML has a formal basis however without a clear semantic and rather inconsistent.
Semantics for individual diagram types exists, however a formalized integrated
semantics is still lacking, making difficult to define, rigorous analysis techniques
(Lankhorst, 2009)
Although UML is a widely recognized and used modelling standard, it is frequently
criticized. The relations between modelling concepts are often ill-defined and models

A-7
are only clear to those who have a sound background in computer science, in
particular in object orientation (Lankhorst, 2009).
One of the most negative critiques is related to the linguistic incoherence being
ambiguous and inconsistent leading to many diagrams and constructs that are
redundant, infrequently used, or even overlapped. Therefore, capabilities of UML
and implementation language mismatch. Another critique is the learning curve and
adopting UML problematic time consuming, especially when required of engineers
lacking the prerequisite skills. The advantage of such richness of UML language may
be a serious disadvantage in the readability and accessibility of the language. The
large number of symbols and diagrams make the learning curve of UML difficult for
new users (Lankhorst, 2009).
Figure 99 – Examples of UML diagrams
In practice, people often draw diagrams with the symbols provided by their CASE
tool, but without the meanings those symbols are intended to provide. Despite the
widespread use of this unified language, important well-known and popular
techniques, almost universally used in industry, such as Data Flow Diagrams and
Structure Charts were not included in the UML’s specification.

A-8
ArchiMate
A high-level modelling language is needed to describe the architecture. ArchiMate
contains methods and best practices to create an EA, being a language for EA models
(Open Group, 2012).
ArchiMate is an Open Group Standard and independent modelling language for
Enterprise Architecture that supports the description, analysis and visualization of
architecture within and across business domains in an unambiguous way.
Diverse tool vendors and consulting firms support the language, which is adopted by
disparate organizations, representing a standard language and vendor-independent
concepts. Nowadays, ArchiMate has evolved to be fully aligned with TOGAF.
As a traditional architectural drawing language, ArchiMate offers a common language
for describing the construction and operation of business processes, organizational
structures, information flows, IT systems, and technical infrastructure. This insight
helps stakeholders to design, assess, and communicate the consequences of decisions
and changes within and between these business domains.
The current version of ArchiMate (2.0) has been improved and expanded based on
many years of practical experience of modelling and analysis of EA by a worldwide
user base. It enables the creation of fully integrated models of the organization’s
enterprise architecture, the motivation for it, and the programs, projects and
migration paths to implement it.
The ArchiMate language, as described in its technical Standard (Open Group, 2012),
provides a graphical representation, that helps to create consistent and integrated
model.
The language consists of active structure elements, behavioural elements and passive
structure elements. The active structure elements are the actors, application
components and devices that display actual behaviour or dynamic aspect. The active
structure concepts are assigned to behavioural concepts, to show who or what
performs the behaviour. The passive structure elements are the objects on which
behaviour is performed.
In the domain of information-intensive organizations, which is the main focus of the
language, there are usually information or data objects, but they may also be used to
represent physical objects. These three aspects – active structure, behaviour, and
passive structure – have been inspired by natural language, where a sentence has a
subject (active structure), a verb (behaviour), and an object (passive structure). Natural

A-9
language is the basis of theoretical framework commonly referred as speech-act
theory, provides concepts for modelling (Eertink et al., 1999). DEMO (Dietz, 2006) is
one of methods and tools built on this theory.
Language Suitability for Enterprise Architecture
From an overview of some languages for modelling EA, we identified ArchiMate as
the language that covers all domains in the area of organizations, namely, business
processes, applications, and technology. Each existing modelling languages emphasize
some elements, but do not provide an overall solution for enterprise architecture. This
is because the most of such methods originate from defined scope and defined goals
and objectives.
As a conclusion, we may say that languages like UML are ideal for modelling
solutions. However, they do not scale well in EA. Thereafter, besides a lightweight
and scalable language, ArchiMate distinguishes itself from other languages such as
UML by its enterprise modelling scope, and meets the need for a modelling language
for Enterprise Architectures.

B-1
Appendix B – EA FRAMEWORKS
Virtually all activities require information about the organization’s assets, business
processes, applications and other additional information (Spewak & Hill, 1992).
Organizations faced this need to define and document the current structure and
behavior of their processes, information systems, and organizational sub-units, but no
standard solution was available.
In 1996, the Clinger-Cohen Act, also known as the Information Technology
Management Reform Act, demands that every government organization must have
an IT architecture as an integrated framework related to information technology that
allows to achieve the defined strategic objectives and information resources
management goals (Lankhorst, 2009).
Different needs, scopes and authors have suggested distinct representations and
architectural frameworks, decompositions or domains, having in common principles
like: a holistic representation of organizations; relationships between artifacts and
architectures; independence and connection among layered architectures, each as a
composition of sub–architectures or domains (Hoogervorst, 2004).
Disparate authors have suggested distinct architectural frameworks, for example,
Zachman Framework, ISO/IEC/IEEE 4210, IAF, E2AF, TEAF, CEO just to name
a few.
Zachman Framework
From the ending of the 1980s’ Zachman (Zachman, 1987) developed what is now
known as “The Zachman Framework”, as the basis of knowledge and representation
on the organization itself, assuming the methodology that best enables the planning
and development of systems and IT aligned with business (Zachman, 1987; Open
Group, 2011).
Despite the field of enterprise architecture started in 1987, with the publication in the
IBM Systems Journal with a paper (Zachman, 1987) where the author laid out both
the challenge and the vision of enterprise architecture that would guide the field for
the next 20 years, the Zachman framework is much more a taxonomy for organizing
architectural artifacts than a framework. The Zachman framework is therefore a
taxonomy for organizing architectural artifacts that takes into account both who the
artifact targets and what particular issue is being addressed, as a simply logical
structure for classifying and organizing the descriptive representations of an

B-2
organization that are significant to the management of the organization, as well s to
the development of the organization’s systems (Zachman, 1997).
As illustrated with Figure 100, the Zachman Framework identifies 36 views on
architecture (“cells”), based on six levels (scope, enterprise, logical system, technology,
detailed representations and functioning organization) and six aspects (data, function,
network, people, time, motivation).
The 36 categories describe structures as well as organizations and all of its goals,
people, and technologies. The framework depicts the design artifacts that constitute
the intersection between rows, the roles in the design process in (owner, designer,
builder, subcontractor, and user), and columns, the product abstractions (what, how,
where, who, when, and why).
Each row represents a particular and unique perspective. The deliverables from each
perspective detail the solution and translate it to the lower row, taking into account
the requirements from each perspective and the restraints imposed. The constraints of
each perspective are additive. For example, the constraints of higher rows affect the
rows below.
Figure 100 – Zachman Framework
The six categories of the underlying interrogatives (what, how, where, who, when, and
why) form the columns of the Zachman Framework. Each column has a defined focus
that remains constant and uniquely defined, yet related across and down the matrix.

B-3
The cells make the architectural descriptive representations explicit from the
intersections between rows and columns, in other words, by the intersection of a
perspective and a focus, becoming distinctive, unique, and explicit per the
perspective’s focus.
Advantages of the Zachman framework are that is easily understandable, addresses
the enterprise as a whole, is defined independently of tools or methodologies, and any
issues can be mapped against it to understand where they fit.
Besides the use of framework in the designation, we cannot use Zachman’s approach
as a sequence of steps. Actually, the Zachman framework is instead a way to organize
and map organization’s dimensions and views.
As handicaps we may identify the large number of cells in the Zachman framework,
which is an obstacle for the practical applicability of the framework, and the relations
between the different cells are not that well specified (Lankhorst, 2009).
Notwithstanding these drawbacks, Zachman is to be credited with providing the first
comprehensive framework for enterprise architecture, and his work is still widely used.
ISO/IEC/IEEE 42010
ISO/IEC/IEEE 42010 is an IEEE standard, a “recommended practice”, following its
predecessor, IEEE 1471. The standard makes a strict distinction between
architectures and architecture descriptions, and is applied in the architectural
description of a system, software and enterprise architectures.
This standard uses the civil architecture metaphor to describe software system
architectures. In this sense, it is similar to the framework of Zachman, although it does
not try to standardize the system architecture by establishing a fixed number, or the
nature of views (as in the case of the cells of Zachman’s framework) (Lankhorst, 2009).
Besides does not standardize the process of developing architectures, neither
recommend any modelling languages, methodologies, or standards, it aims to
standardize the practice of architecture description by defining standard terms,
presenting a conceptual foundation for expressing, communicating and reviewing
architectures and specifying requirements that apply to architecture descriptions,
architecture frameworks and architecture description languages. Therefore,
ISO/IEC/IEEE 42010 provides, a valuable set of concepts which reflect the
‘generally accepted trends in practice for architecture description’ and which ‘codify
those elements on which there is consensus’.

B-4
One of main standard’s main ideas is a clear separation between an architecture and
its architecture descriptions (defined as means to record architectures), and the central
role of the relationship between architectural viewpoint and architectural view
(Lankhorst, 2009).
Figure 101 - ISO/IEC/IEEE 42010 conceptual framework
The standard also provides a conceptual framework, illustrated with Figure 101, to
explain how the key terms relate to each other in a conceptual model for architecture
description and the stakeholders’ role in the creation and use of an architecture
description. Related to the conceptual framework is the provision of a number of
scenarios for the architectural activities during the life cycle. Furthermore, the
standard gives six architecture description practices.
ISO/IEC/IEEE 42010 also provides a number of relevant architectural viewpoints
together with their specifications in terms of concerns, languages, and modelling and
analysis methods (Lankhorst, 2009).
One important note is the architecture descriptions that are compliant with
ISO/IEC/IEEE 42010 can be used to meet the requirements of other standards.

B-5
The Integrated Architecture Framework
The Integrated Architecture Framework (IAF), illustrated with Figure 102, support
the integrated architectural design of business and IT based in four main architectures
areas, namely Business, Information, Information Systems, and Technology
Infrastructure.
Transversal to architectures areas, the IAF have abstraction levels answering Why,
What, How, With What, and When creating a complete and integrated architectural
description of the IT enabled Enterprise (Maes et al., 2000).
The IAF is strongly influenced by the Enterprise Architecture Framework from
Zachman (Zachman, 1987), and is similar to the levels of abstraction of Zachman’s
Information System’s Architecture.
Figure 102 - Integrated Architecture Framework (IAF)
Extended Enterprise Architecture Framework
The Extended Enterprise Architecture Framework (E2AF), in Figure 103, is based on
ideas and influences from other frameworks, namely the influences of Zachman
framework, Enterprise Architecture Planning (EAP), the Integrated Architecture
Framework (IAF) and the Federal Enterprise Architecture Framework (Schekkerman,
2004).
The E2AF supports collaboration and communication with stakeholders involved
across four rows corresponding to four areas (business, information, information
systems, and technology infrastructure), and six columns with distinguished main
levels of concern abstraction (contextual - why, environmental - with who, conceptual
- what, logical - how, physical - with what, transformational - when).

B-6
Figure 103 - Extended Enterprise Architecture Framework (E2AF)
The Treasury Enterprise Architecture Framework
The Treasury Enterprise Architecture Framework (TEAF), Figure 104, received
influences from Federal Enterprise Architecture Framework (FEAF) and from
TOGAF and was conceived to plan and develop the enterprise architecture in all
bureaus and offices of the Treasury Department from USA.
Figure 104 - Treasury Enterprise Architecture Framework (TEAF)

#


Enterprise
Architecture
Visioning
EA
Scope
&
Context
Goals /
Objectives &
Requirements
ganizational
Impact
ation
Opportunities
&
Solutions
ementation
vernance


Enterprise
Architecture
Visioning
EA
Scope
&
Context
Goals /
Objectives &
Requirements
ganizational
Impact
ation
Opportunities
&
Solutions
ementation
vernance
@


Technology -
Infrastructure
Information–
Systems
Information
Business
What?What?
Conceptual Level
Goals & Objectives
Requirements
What?What?
Conceptual Level
Goals & Objectives
Requirements
How?
Logical Level
Logical Representation
How?
Logical Level
Logical Representation
With what?
Physical Level
Solution
Representation
With what?
Physical Level
Solution
Representation
When?
Transformational Level
Enterprise Impact
When?
Transformational Level
Enterprise Impact
Contextual Level
Vision / Strategy
Business / Technology
Drivers
Scope
Why?
Environmental Level
Value Net Relations
Cooperating /
Collaborating Elements
With Who?
Environmental Level
Value Net Relations
Cooperating /
Collaborating Elements
With Who?Abstraction LevelsAbstraction LevelsAbstraction Levels
Aspect AreasAspect AreasAspect Areas
TheFutureBusiness&the
Organisation
Theconcepts,whatdowewant?
Logicaldirections&solutions
Physicalsolutionsbasedon
change,redesign,productsor
techniques
Changefromtheexisting
toafuturesituation
TheExtendedEnterpriseEnvironment


B-7
The stakeholders and propose of this framework is very particular, but also was
developed along four rows perspectives, from the planner to the builder, and the four
columns that correspond to different views (functional, information, organizational,
and infrastructure).
The CEO Framework
The CEO Framework proposed by the Enterprise Engineering Center, or CEO for
short in Portuguese (Vasconcelos et al., 2001; Vasconcelos, Sousa, & Tribolet, 2003),
as illustrated with Figure 105, present an UML profile to apply the enterprise
architecture principles in the development of Information System Architectures (ISA).
Figure 105 - CEO Framework Metamodel Profile
The proposed framework represents dependencies between organizational dimension
and systems. The CEO Framework have been developed in more recent research and
the current core concepts of the CEO framework are: business processes, information
entities, information systems perspective, and technological point of view of concepts
(Vasconcelos et al., 2004). This development is aligned with Spewak (Spewak & Hill,
1992) three division levels (Vasconcelos et al., 2003):
• Information Architecture – set of main data types that support business;
• Application Architecture – defines applications needed for data management
and business support;
• Technological Architecture – represents the main technologies used in
application implementation and the infrastructures that provide an
environment for IS deployment.

Appendix C – EA DEFINITIONS AND CORE CONCEPTS
Whatever the framework or approach related with EA, in some way have the followed
generic concepts (Spewak & Hill, 1992; Vieira et al., 2004; Bernard, 2005;
Schekkerman, 2006; Vasconcelos et al., 2007; Winter & Fischer, 2007; Nakakawa,
2008; Lankhorst, 2009; Nabiollahi et al., 2010; Gama, Mira da Silva, et al., 2011;
Open Group, 2011):
Activity is a unit of work that is performed within a business process by one job
function and at one time with one mode of operation. Usually, an activity is a
collection of tasks granted to an actor, at some point in time, in the scope of particular
interaction contexts.
Actor is a person, organization, or system that is outside the consideration of the
architecture model, but interacts with it.
Application is a deployed and operational IT system that supports business functions
and services. Applications use data and are supported by multiple technology
components but are distinct from the technology components that support the
application.
Application Component is a modelling construct within a process integration
scenario. From a logical point of view, it would be either one or more business
systems or an integration process as an encapsulation of application functionality that
is aligned to implementation structuring.
Application Function is a discrete piece of functional behaviour that an application
provides.
Application Interface is the connection, or set of functions, between the application
software and the application platform. Is the most common means by which a
software programmer invokes other software functions.
Application Platform is the collection of technology components of hardware and
software that provide the services used to support applications.
Application Service is a well-defined component of functional behaviour, specifying
the service in terms of what it does, that provides a logical grouping of Application
Functions. This is useful, to a service-based approach. The application service enables
the capture on how to structure and provide application functionality.
Application Software is software entities that have a specific business purpose

C-2
Artefact is an architectural work product that describes an aspect of the architecture.
Represents a (potentially re-usable) component of business, IT, data, or architectural
capability that can be combined with other various levels of detail to deliver
architectures and solutions. Whereas documents in ITIL may be considered as being
artefacts in EA, in this case artefacts are contracts, plans, job descriptions,
organizational structures, processes, diagrams, lists, databases among many other
document types (Thorn, 2007).
Business Event is created every time a business object in the database changes.
These events contain the business objects that were changed during a transaction, and
act as a focal point for determining who is interested in the event. This is the definition
of an event-driven architecture. If the primary purpose of an application is to collect
the most up-to-date master information, your business logic needs to forward these
events to downstream warehousing solutions to keep their databases up-to-date.
Business Function delivers business capabilities closely aligned to an organization.
Business Objects is the processing services access the data and interact directly with
the databases. Which services become involved in processing an object is determined
by whether the object is being scheduled or viewed on demand. Viewer choice also
plays a role in determining which servers are involved in object processing.
Business Process is a triggered sequence of value-added activities performed by
actors that, by the use or consume of resources, transform a set of inputs into
predictable outputs in order to accomplish a defined goal. A process can be
decomposed into sub-processes, and can show operation of a function or service (at
next level of detail). The process should be monitored, compared against the previous
results and controlled so as to improve in a continual cycle. Processes may also be
used to link or compose organizations, functions, services, and processes.
Business Service supports business capabilities through an explicitly defined
interface and is explicitly governed by an organization.
Communication Network is a set of products, concepts, and services that enables
the connection of computer systems for the purpose of transmitting data and other
forms between the systems.
Communication System is a set of assets (transmission media, switching nodes,
interfaces, and control devices) that will establish linkage between users and devices.
Conceptual data-model, also called Domain models, establish the basic concepts
and semantics of a given domain and help to communicate these to a wide audience

of stakeholders. Conceptual models also serve as a common vocabulary during the
analysis stages of a project.
Contract can be defined as an agreement between a service consumer and a service
provider that establishes functional and non-functional parameters for interaction.
Data is a basic unit of information having a meaning and that may have
subcategories (data items) of distinct units and values. Therefore, data items refer to an
elementary description of things, events, activities, and transactions that are recorded,
classified, and stored, but not organized to convey any specific meaning. Data items
can be numeric, alphabetic, figures, sounds, or images. A database consists of stored
data items organized for retrieval.
Data Entity is an encapsulation of data that is recognized by a business domain
expert as a discrete concept. Data entities can be tied to applications, repositories, and
services and may be structured according to implementation considerations.
Database is the logical view of the data models, data standards, and data structure. It
includes a definition of the physical databases for the information system, their
performance requirements, and their geographical distribution.
Function delivers business capabilities closely aligned to an organization, but not
explicitly governed by the organization.
Goal is the high-level statement of intent or direction for an organization. Typically
used to measure success of an organization.
Hardware can be defined as the set of devices an physical equipment, as opposed to
programs, procedures, rules, and associated documentation.
Information is data that have been organized so that they have meaning and value
to the recipient. The recipient interprets the meaning and draws conclusions and
implications. Therefore, information is the interpretation in a defined context of any
communication or representation of facts, data, or opinions, in any medium or form,
including textual, numerical, graphic, cartographic, narrative, or audio-visual forms.
Interface is defined as the interconnection and inter-relationships between two
artefacts: devices, applications, or the user and an application.
Infrastructure Components is the Technology Infrastructure component
describes and identifies the physical layer including, the functional characteristics,
capabilities, and interconnections of the hardware, and communications, including
networks, protocols, and nodes.

C-4
Infrastructure Service is the services that expose the infrastructure capabilities. An
infrastructure service may be composed of other infrastructure services, virtualized
services, and physical services. The foundational principles of composition of services
apply to infrastructure services just as they do within the application domain. An
operational infrastructure services facilitate the creation of the environment required
to enable the delivery, deployment and management of applications and information.
Logical Data-model adds further detail to conceptual model elements and refines
the structure of the domain. One benefit of a logical data-model is that it provides a
foundation on which to base the physical model and subsequent database
implementation.
Meta-data can be defined as data about data, of any sort in any media, which
describes the characteristics of an entity.
Objective is a time-bounded milestone for an organization used to demonstrate
progress towards a goal.
Organizational Service is the externally visible behaviour is modelled by the
concept organizational service, which represents a unit of functionality that is
meaningful from the point of view of the environment.
Organizational Structure is one of the key design components of enterprise
architecture. People and organizational structure is about authority and roles to
achieve business goals.
Platform is a combination of technology infrastructure products and components
that provides that prerequisites to host application software.
Platform Service is a technical capability required to provide enabling
infrastructure that supports the delivery of applications
Procedure is a special type of function defined by its behaviour. The main
characteristic property of a procedure is that its description is executable.
Repository is a system that manages all of the data of an organization, including
data and process models and other organization information. Hence, the data in a
repository is much more extensive than that in a data dictionary, which generally
defines only the data making up a database.
Role is the part an individual plays in an organization and the contribution they make
through the application of their skills, knowledge, experience, and abilities. A role is
the usual or expected function of an actor, in a particular action or event. Role focuses

on the actor while task places emphasis on the activity. An Actor may have a number
of roles.
Stakeholder is an individual, team, or organization (or classes thereof) with interests
in, or concerns relative to, the outcome of the architecture. Different stakeholders with
different roles will have different concerns.
Strategy is the central integrated concept of how to achieve the organization’s
objectives. The essence of strategy is choosing a set of core business activities to create
value, and performing those business activities in the most optimal manner.
Task is defined as a fundamental unit of activity work, a job function. Tasks are
assigned to individual or grouped actors (IT staff) through their job positions in
processes.

Appendix D – ARCHIMATE CONCEPTS AND DEFINITIONS
Definitions from the ArchiMate 2.0 specification:
Figure 106 - ArchiMate’s Business Layer Metamodel (Open Group, 2012)
Value is defined as the relative worth, utility, or importance of a business service or
product that makes some party appreciate it (product or service).
Product is defined as a coherent collection of services, accompanied by a
contract/set of agreements that specifies the characteristics, rights, and requirements
for their use, which is offered as a whole to (internal or external) customers.
Contract is defined as a formal or informal specification of an agreement that
specifies the rights and obligations associated with a product.
Meaning is defined as the contribution of (the representation of) a business object to
the knowledge or expertise of some actor, given a particular context.
Business object is the passive entities such as business processes or functions that are
manipulated by behaviour.
Representation is defined as a perceptible form of the information carried by a
business object, such as a document.

D-2
Business service is defined as a coherent piece of functionality (service) that offers
added value to the environment, fulfilling a business need for a customer (internal or
external to the organization) independent of the way this functionality is realized
internally.
Business process is defined as a behaviour element that groups a ‘flow’ of activities,
with one or more clear starting points and leading to a clearly defined result, as a
defined set of products or business services.
Business function is defined as a behaviour element, which offers functionality that
may be useful for one or more business processes.
Business interaction is defined as a behaviour element that describes the
behaviour of a business collaboration of two or more business roles.
Business event is defined as something that happens (internally or externally) and
may influences behaviour (business processes, functions, or interactions).
Business interface is defined as a point of access (logical or physical) where a
business service is made available to the environment and can be accessed.
Business role is defined as the responsibility for performing specific behaviour, to
which an actor can be assigned.
Business actor is an organizational active entity that is capable of performing
behaviour (i.e., the ‘subject’ of behaviour).
Business collaboration is defined as an aggregate of two or more business roles
that work together to perform collective behaviour (interactions).
Location is defined as a conceptual point or extent in space.

Figure 107 - Summary of Business Layer Concepts (Open Group, 2012)

D-4
Figure 108 - ArchiMate’s Application Layer Metamodel (Open Group, 2012)
Data object is defined as a coherent, self-contained piece of information (a passive
element) suitable for automated processing.
Application service is defined as a service that exposes automated behaviour.
Application function is defined as the internal behaviour of a component needed to
realize one or more application services.
Application interaction is defined as the behaviour of a collaboration of two or
more application components.
Application interface defines the set of operations and events that are provided by
the component, or those that are required from the environment.
Application component is a self-contained part of a system that encapsulates its
contents and exposes its functionality through a set of interfaces
Application collaboration is a collective of application components, which
perform application interactions.

Figure 109 - Summary of Application Layer Components (Open Group, 2012)

D-6
Figure 110 - ArchiMate’s Technology Layer Metamodel (Open Group, 2012)
Artefact 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.
Infrastructure service is defined as an externally visible unit of functionality,
provided by one or more nodes, exposed through well-defined interfaces, and
meaningful to the environment.
Infrastructure function is defined as a behaviour element that groups
infrastructural behaviour that can be performed by a node.
System software represents a software environment for specific types of
components and objects that are deployed on it in the form of artefacts.
Infrastructure interface is defined as a point of access or the (logical) location
where the infrastructural services offered by a node can be accessed by other nodes or
by application components from the application layer
Node is defined as a computational resource upon which artefacts may be stored or
deployed for execution, i.e., represents a structural entity in the technology layer.
Device is defined as a hardware resource upon which artefacts may be stored or
deployed for execution.
Communication path is defined as the relation between two or more nodes,
through which these nodes can exchange data or information.
Network is defined as the physical realization of a communication path, i.e., a
physical communication medium between two or more devices.

Figure 111 - Summary of Technology Layer Components (Open Group, 2012)

D-8
Figure 112 - ArchiMate’s Motivation Extension Metamodel (Open Group, 2012)
Motivational element defines an element that provides the context or reason lying
behind the architecture of an enterprise.
Stakeholder is defined as the role of an individual, team, or organization (or classes
thereof) with interests in, or concerns relative to a system or to the outcome of the
architecture.
Driver is defined as something that creates, motivates, and fuels the change in an
organization.
Assessment is defined as the outcome of some analysis of some driver.
Goal is defined as an end state that a stakeholder intends to achieve.
Requirement is defined as a statement of need that must be realized by a system.
Constraint is defined as a restriction on the way in which a system is realized.
Principle is defined as a normative property of all systems in a given context, or the
way in which they are realized.

Figure 113 - Summary of Motivation Extension Metamodel (Open Group, 2012)
© 2009-2012 The Open Group, All Rights Reserved
ArchiMate®
2.0 Specification 127
Concept Definition Notation
Goal An end state that a stakeholder intends to
achieve.
Requirement A statement of need that must be realized by
a system.
Constraint A restriction on the way in which a system is
realized.
Principle A normative property of all systems in a
given context, or the way in which they are
realized.
10.3 Relationships
The metamodels and examples from the previous sections show the different types of
relationships that can be used between two motivational elements and between one motivational
element and one core element. This section provides a more precise description of these
relationships.
10.3.1 Aggregation Relationship
The aggregation relationship models that some intention is divided into multiple intentions.
The aggregation relationship is generally used to describe an intention in more detail by
decomposing the intention into multiple, more concrete intentions.
Figure 69: Aggregation Notation
Alternatively, an aggregation can be expressed by nesting the model elements.
Example
The models below show the two ways to express the decomposition of goal Reduce workload
employees into the sub goals Reduce interaction with customer and Reduce manual work.
© 2009-2012 The Open Group, All Rights Reserved
Personal PDF Edition. Not for redistribution
126 Technical Standard (2012)
Example 53: Principle
10.2.8 Summary of Motivational Concepts
Table 34 gives an overview of the motivational concepts, with their definitions.
Table 26: Motivational Concepts
Stakeholder The role of an individual, team, or
organization (or classes thereof) that
represents their interests in, or concerns
relative to, the outcome of the architecture.
Driver Something that creates, motivates, and fuels
the change in an organization.
Assessment The outcome of some analysis of some
driver.

D-10
Figure 114 – Implementation and Migration Extension (Open Group, 2012)
Architecture 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.
Business activity can be defined as the smallest level of decomposition of business
behaviour.
Concern is an interest of a stakeholder with regards to the architecture description of
some system, resulting from the stakeholder’s goals, and the present or future role(s)
played by the system in relation to these goals.
Deliverable is defined as a precisely-defined outcome of a work package.
Domain is any subset of a conception (being a set of elements) of the universe that is
conceived of as being some ‘part’ or ‘aspect’ of the universe.
Gap is defined as an outcome of a gap analysis between two plateaus.
Model is a purposely abstracted and unambiguous conception of a domain.
Modelling is the act of purposely abstracting a model from (what is conceived to be)
a part of the universe.
Plateau is defined as a relatively stable state of the architecture that exists during a
limited period of time.
Semantic model is an interpretation of a symbolic model, expressing the meaning
of the symbols in that model.
Structure element usually defines an active element that is capable of performing
behaviour like an actor, a role component, a business actor, an application
component, a device, etc. A structure element can also be defined as passive as an

object on which behaviour is performed. A behaviour element is defined as a unit of
activity performed by one or more active structure elements.
Service is defined as a unit of functionality that a system exposes to its environment,
while hiding internal operations, which provides a certain value (monetary or
otherwise).
Symbolic model expresses properties of architectures of systems by means of
symbols that refer to reality.
View is a representation of a system from the perspective of a related set of concerns.
Viewpoint is a specification of the conventions for constructing and using a view; a
pattern or template from which to develop individual views by establishing the
purposes and audience for a view and the techniques for its creation and analysis.
Work package is defined as a series of actions designed to accomplish a unique goal
within a specified time.
Figure 115 – Implementation and Migration Extension (Open Group, 2012)
11.2.5 Summary of Implementation and Migration Concepts
Table 34 gives an overview of the implementation and migration concepts, with their definitions.
Table 34: Motivational Concepts
Work Package A series of actions designed to accomplish
a unique goal within a specified time.
Deliverable A precisely-defined outcome of a work
package.
Plateau A relatively stable state of the architecture
that exists during a limited period of time.
Gap An outcome of a gap analysis between
two plateaus.
11.3 Relationships
The Implementation and Migration extension re-uses the standard ArchiMate relationships.
11.4 Cross-Aspect Dependencies
Figure 78 shows how the implementation and migration concepts can be related to the
ArchiMate core concepts.
Figure 78: Relationships between Implementation & Migration Extension and the ArchiMate Core

Appendix E – SOA ELEMENTS
From different sources, we identified SOA elements along three layers as illustrated in
the following table (Eriksson & Penker, 2000; OASIS, 2006; Jung, 2009; Open Group,
2009; Alwadain et al., 2010).
Table 26 – SOA’s Layers Concepts
Layer Concept
Business Actor
Business Interface
Business Service
Measure
Contract
Service
Service Consumer
Service Description
Service Function
Service Interface
Service Policy
Service Provider
Application Application Interface
Application Service
Application Description
Application Policy
Infrastructure InfrastructureService
Infrastructure Policy
Infrastructure Interface
Infrastructure Description
The identified SOA concepts are as follows (Eriksson & Penker, 2000; OASIS, 2006;
Open Group, 2009; Alwadain et al., 2011):
Actor specifies a person, organization, or system played by a user or any other system
that initiates or interacts through activities with a defined subject. Actors may be
internal or external to an organization, representing roles played by human users,

E-2
external hardware, or other subjects. An actor always has some interest in using the
functionality the system provides however, an actor does not necessarily represent a
specific physical entity but merely a particular facet (i.e., “role”) of some entity that is
relevant. A single physical instance may play the role of several different actors and,
conversely, a given actor may be played by multiple different instances.
Application Interface is the ability to connect to other applications, or set of
functions, between application software and/or the application platform. An
application interacts with resources through an interface and can cause the states of
resources to change. An application also interacts with other applications by
generating or handling events.
Application Service is an externally visible unit of functionality, provided by one or
more components, exposed through well-defined interfaces, and meaningful to the
environment. Application service is usually identified in the metamodels.
Business Interfaces is the (logical or physical) locations where the services that a
role offers to the environment can be accessed.
Business Service is a coherent piece of functionality that offers added value to the
environment, independent of the way this functionality is realized internally. A
Business Service represents business logic and is a self-contained, independent unit.
Infrastructure Interface is the (logical) location where the infrastructural services
offered by a node can be accessed by other nodes or by application components from
the application layer.
Infrastructure Service is a prescribed access provided consistent with constraints
and policies specified by the service description. The interface is the externally visible
unit of functionality comprises the specifics of how to access the underlying
capabilities.
Measure is an indicator or factor that can be tracked, usually on an on-going basis, to
determine success or alignment with objectives and goals.
Policy/Contract is a statement of obligations, constraints or other conditions of use
of an owned entity as defined by a participant. A policy represents some constraint or
condition on the use, deployment or description of an owned entity as defined by any
participant. Contract, a consumer and utility agree on constraints and polices, and
typically, represents an agreement by two or more parties.

Service can be defined as a logical representation of a repeatable business activity
that has a specified outcome. A service is self-contained, may be composed of other
services, and is a "black box" to its consumers.
Service Consumer is an entity seeking to satisfy a particular need through the use
capabilities offered by means of a service
Service Description represents the information needed in order to use a service.
The information needed in order to use, or consider using, a service
Service Function is the performance of work provides the means to support typical
usage underlying technical assumptions that determine the limits of functionality
exposed by the service or of the underlying capability. This is often the characteristic
most in focus. Besides just defining the essential characteristics, it also involves finding
ways that simplify the usability of the system. Much of the basis for finding the
functional requirements on the system can be derived from the business model.
Service Interface is the means by which the underlying capabilities of a service are
accessed usually for interacting with other service.
Service Policy/Contract is a measurable assertion that governs the requirements
and expectations of two or more parties. Unlike policy enforcement, which is usually
the responsibility of the policy owner, contract enforcement may involve resolving
disputes between the parties to the contract.
Service Provider is an entity (person or organization) that offers the use of
capabilities by means of a service.

Appendix F – ITIL ARTEFACTS AND PROCESSES
ITIL’s 26 processes are presented in the following Figure 116, distributed by the
overall Service Lifecycle.
Figure 116 - ITIL Processes Across the Service Lifecycle
From ITIL books, we identified the ITIL concepts as follows (Cabinet Office, 2011b,
2011d, 2011f, 2011e, 2011c):
Activity is a set of actions designed to achieve a particular result. Activities are
usually defined as part of Processes and are documented in Procedures.
Agreement is a document that describes a formal understanding between two or
more parties.
Application can be defined as software that provides Functions that are required by
an IT Service. Each Application may be part of more than one IT Service. An
Application runs on one or more Servers or Clients.
Application Service Provider is an External Service Provider that provides IT
Services using Applications running at the Service Provider’s premises. Users access
the Applications by network connections to the Service Provider.
Architecture is the structure of a System or IT Service, including the Relationships
of Components to each other and to the environment they are in. Architecture also

F-2
includes the Standards and Guidelines that guide the design and evolution of the
System.
Assessment is the inspection and analysis to check whether a Standard or set of
Guidelines is being followed, that Records are accurate, or that Efficiency and
Effectiveness targets are being met. See also Audit.
Asset is any Resource or Capability. Assets of a Service Provider including anything
that could contribute to the delivery of a Service.
Attribute is a piece of information about a Configuration Item. Examples are: name,
location, Version number, and Cost. Attributes of CIs are recorded in the
configuration management Database (CMDB).
Business Customer is a recipient of a product or a Service from the Business. For
example, if the Business is a car manufacturer then the Business Customer is someone
who buys a car.
Business Process is a Process that is owned and carried out by the Business. A
Business Process contributes to the delivery of a product or Service to a Business
Customer. For example, a retailer may have a purchasing Process that helps to deliver
Services to its Business Customers. Many Business Processes rely on IT Services.
Business Service is an IT Service that directly supports a Business Process, as
opposed to an Infrastructure Service, which is used internally by the IT Service
Provider and is not usually visible to the Business. The term Business Service is also
used to mean a Service that is delivered to Business Customers by Business Units. For
example, delivery of financial services to Customers of a bank, or goods to the
Customers of a retail store. Successful delivery of Business Services often depends on
one or more IT Services.
Business Unit is a segment of the Business that has its own Plans, Metrics, income
and Costs. Each Business Unit owns Assets and uses these to create value for
Customers in the form of goods and Services.
Category is a named group of things that have something in common. Categories are
used to group similar things together. For example, Cost Types are used to group
similar types of Cost. CI Types are used to group similar types of Configuration Item.
Client is a generic term that means a Customer, the Business or a Business Customer.
Collaboration are services provide value to the customer when cooperative Business
Services are conducted without the constraints of location or device.

Component is a general term that is used to mean one part of something more
complex. For example, a computer System may be a component of an IT Service, an
Application may be a Component of a Release Unit. Components that need to be
managed should be Configuration Items.
Configuration is a generic term, used to describe a group of Configuration Items
that work together to deliver an IT Service, or a recognizable part of an IT Service.
Configuration is also used to describe the parameter settings for one or more CIs.
Configuration Item (CI) is any Component that needs to be managed in order to
deliver an IT Service. Information about each CI is recorded in a Configuration
Record within the configuration management System and is maintained throughout
its Lifecycle by Configuration Management. CIs are under the control of Change
Management. CIs typically include IT Services, hardware, software, buildings, people,
and formal documentation such as Process documentation and SLAs.
Configuration Management Database (CMDB) is a database used to store
Configuration Records throughout their Lifecycle. The configuration management
System maintains one or more CMDBs, and each CMDB stores Attributes of CIs,
and Relationships with other CIs.
Configuration Management System (CMS) is a set of tools and databases that
are used to manage an IT Service Provider’s Configuration data. The CMS also
includes information about Incidents, Problems, Known Errors, Changes and
Releases; and it may contain data about employees, Suppliers, locations, Business
Units, Customers and Users. The CMS includes tools for collecting, storing,
managing, updating, and presenting data about all Configuration Items and their
Relationships. The CMS is maintained by configuration management and is used by
all IT Service Management Processes.
Contract is a legally binding Agreement between two or more parties.
Critical Success Factor (CSF) is something that must happen if a Process, Project,
Plan, or IT Service is to succeed. KPIs are used to measure the achievement of each
CSF. For example a CSF of ‘protect IT Services when making Changes’ could be
measured by KPIs such as ‘percentage reduction of unsuccessful Changes’,
‘percentage reduction in Changes causing Incidents’, etc.
Customer is someone who buys goods or Services. The Customer of an IT Service
Provider is the person or group that defines and agrees the Service Level Targets. The
term Customers is also sometimes informally used to mean Users, for example ‘this is
a Customer-focused Organization’.

F-4
Definitive Media Library (DML) is one or more locations in which the definitive
and approved versions of all software Configuration Items are securely stored. The
DML may also contain associated CIs such as licenses and documentation. The DML
is a single logical storage area even if there are multiple locations. All software in the
DML is under the control of Change and Release Management and is recorded in the
configuration management System. Only software from the DML is acceptable for
use in a Release.
Dependency is the direct or indirect reliance of one Process or Activity on another.
Driver is something that influences Strategy, Objectives or Requirements. For
instance, new legislation or the actions of competitors.
Event can be defined as a change of state that has significance for the management of
a Configuration Item or IT Service. The term Event is also used to mean an Alert or
notification created by any IT Service, Configuration Item or Monitoring tool. Events
typically require IT Operations personnel to take actions, and often lead to Incidents
being logged.
Function is defined as a team or group of people and the tools they use to carry out
one or more Processes or Activities. For example the Service Desk. The term Function
also has two other meanings: An intended purpose of a Configuration Item, Person,
Team, Process, or IT Service. For example one Function of an e-mail Service may be
to store and forward outgoing mails, one Function of a Business Process may be to
dispatch goods to Customers; To perform the intended purpose correctly, ‘The
computer is Functioning’.
Governance insures that Policies and Strategy are actually implemented, and that
required Processes are correctly followed. Governance includes defining Roles and
responsibilities, measuring and reporting, and taking actions to resolve any issues
identified.
Infrastructure Service is an IT Service that is not directly used by the Business, but
is required by the IT Service Provider so they can provide other IT Services. For
example directory services, naming services, or communication services.
IT Infrastructure is all of the hardware, software, networks, facilities, etc. that are
required to develop, Test, deliver, Monitor, Control or support IT Services. The term
IT Infrastructure includes all of the Information Technology but not the associated
people, Processes and documentation.

IT Service is a service provided to one or more Customers by an IT Service
Provider. An IT Service is based on the use of Information Technology and supports
the Customer’s Business Processes. An IT Service is made up from a combination of
people, Processes and technology and should be defined in a Service Level
Agreement.
IT Service Provider is the service provider that provides IT Services to Internal
Customers or External Customers.
Job Description is a document that defines the Roles, responsibilities, skills and
knowledge required by a particular person. One Job Description can include multiple
Roles, for example the Roles of Configuration Manager and Change Manager may
be carried out by one person.
Key Performance Indicator (KPI) is a metric that is used to help manage a
Process, IT Service or Activity. Many Metrics may be measured, but only the most
important of these are defined as KPIs and used to actively manage and report on the
Process, IT Service or Activity. KPIs should be selected to ensure that Efficiency,
Effectiveness, and Cost Effectiveness are all managed.
Metric is something that is measured and reported to help manage a Process, IT
Service or Activity.
Objective is the defined purpose or aim of a Process, an Activity or an Organization
as a whole. Objectives are usually expressed as measurable targets. The term
Objective is also informally used to mean a Requirement.
Operational Level Agreement (OLA) is an Agreement between an IT Service
Provider and another part of the same Organization. An OLA supports the IT
Service Provider’s delivery of IT Services to Customers. The OLA defines the goods
or Services to be provided and the responsibilities of both parties. For example there
could be an OLA: Between the IT Service Provider and a procurement department to
obtain hardware in agreed times; Between the Service Desk and a Support Group to
provide Incident Resolution in agreed times.
Procedure is a document containing steps that specify how to achieve an Activity.
Procedures are defined as part of Processes.
Process is a structured set of Activities designed to accomplish a specific Objective. A
Process takes one or more defined inputs and turns them into defined outputs. A
Process may include any of the Roles, responsibilities, tools and management Controls

F-6
required to reliably deliver the outputs. A Process may define Policies, Standards,
Guidelines, Activities, and Work Instructions if they are needed.
Requirement is a formal statement of what is needed as for a service level
requirement, a project requirement or the required deliverables for a process.
Resource is a generic term that includes IT Infrastructure, people, money or
anything else that might help to deliver an IT Service. Resources are considered to be
Assets of an Organization.
Role is a set of responsibilities, Activities and authorities granted to a person or team.
A Role is defined in a Process. One person or team may have multiple Roles; for
example, the Roles of Configuration Manager and Change Manager may be carried
out by a single person.
Server is a computer that is connected to a network and provides software Functions
that are used by other Computers.
Service is a means of delivering value to Customers by facilitating Outcomes
Customers want to achieve without the ownership of specific Costs and Risks.
Service Contract is a contract to deliver one or more IT Services. The term service
contract is also used to mean any agreement to deliver IT services, whether this is a
legal contract or an SLA.
Service Level Agreement (SLA) is an Agreement between an IT Service Provider
and a Customer. The SLA describes the IT Service, documents Service Level Targets,
and specifies the responsibilities of the IT Service Provider and the Customer. A single
SLA may cover multiple IT Services or multiple customers.
Service Owner is a Role that is accountable for the delivery of a specific IT Service
Service Portfolio is the complete set of Services that are managed by a Service
Provider. The Service Portfolio is used to manage the entire Lifecycle of all Services,
and includes three Categories: Service Pipeline (proposed or in Development); Service
Catalogue (Live or available for Deployment); and Retired Services.
Service Provider is an Organization supplying Services to one or more Internal
Customers or External Customers. Service Provider is often used as an abbreviation
for IT Service Provider.
Specification can be defined as a formal definition of what is needed. A specification
may be used to define technical or Operational Requirements, and may be internal or

external. Many public Standards consist of a Code of Practice and a Specification.
The specification defines the standard against which an organization can be audited.
Strategy is the highest of three levels of Planning and delivery (Strategic, Tactical,
Operational). Strategic Activities include Objective setting and long-term Planning to
achieve the overall Vision.
System is a number of related things that work together to achieve an overall
Objective. For example: A computer System, including hardware, software and
Applications; A management System, including multiple Processes that are planned
and managed together. For example, a Quality Management System; A Database
Management System or Operating System that includes many software modules that
are designed to perform a set of related Functions.
Underpinning Contract (UC) is a Contract between an IT Service Provider and a
Third Party. The Third Party provides goods or Services that support delivery of an
IT Service to a Customer. The Underpinning Contract defines targets and
responsibilities that are required to meet agreed Service Level Targets in an SLA.
User is a person who uses the IT Service on a day-to-day basis. Users are distinct
from Customers, as some Customers do not use the IT Service directly.
Value is something intangible such a service defined in terms of customer’s business
outcomes. Value is the result of two key elements: utility or what the customer
perceives from the attributes of the service; and warranty is how the service delivered
or the positive effect of the service being available when needed.

Appendix G – CONCEPT MAPPING BETWEEN ITIL AND
ARCHIMATE
ArchiMate concept’s cell colour code
Information
(Passive)
Behaviour
Structure
(active)
Motivational
Business Layer
Application layer
Infrastructure
Table 27 – Concept's Mapping Between ITIL and ArchiMate
ITIL concept Definition
ArchiMate
concept
Definition
Activity
A set of actions designed to
achieve a particular result.
Activities are usually defined
as part of Processes and are
documented in Procedures.
Business
activity
Business activity can be
defined as the smallest level of
decomposition of business
behaviour.
Agreement
A document that describes a
formal understanding
between two or more
parties.
Contract
Contract is defined as a formal
or informal specification of an
agreement that specifies the
rights and obligations
associated with a product.
Application
Service
A provision of IT Services
using Applications running
at the Service Provider's
premises. Users access the
Applications by network
connections to the Service
Provider
Application
service
Application service is defined
as a service that exposes
automated behaviour.
Application
Software that provides
Functions that are required
by an IT Service. Each
Application may be part of
more than one IT Service.
An Application runs on one
or more Servers or Clients.
Application
collaboration
Application collaboration is a
collective of application
components, which perform
application interactions
Application
Software that provides
Functions that are required
by an IT Service. Each
Application may be part of
more than one IT Service.
Application
component
Application component is a
self-contained part of a system
that encapsulates its contents
and exposes its functionality
through a set of interfaces

G-2
An Application runs on one
or more Servers or Clients.
Application
function
Application function is defined
as the internal behaviour of a
component needed to realize
one or more application
services.
Application
interaction
Application interaction is
defined as the behaviour of a
collaboration of two or more
application components.
Application
interface
Application interface defines
the set of operations and
events that are provided by
the component, or those that
are required from the
environment.
Objective
Objective is the defined
purpose or aim of a Process,
an Activity or an
Organization as a whole.
Objectives are usually
expressed as measurable
targets. The term Objective
is also informally used to
mean a Requirement.
Business
object
Business object is the passive
entities such as business
processes or functions that are
manipulated by behaviour.
Attribute
A piece of information about
a Configuration Item.
Examples are: name,
location, Version number,
and Cost. Attributes of CIs
are recorded in the
configuration management
Database (CMDB).
Artefact
Artefact 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.
Business
Customer
A recipient of a product or a
Service from the Business.
For example, if the Business
is a car manufacturer then
the Business Customer is
someone who buys a car.
Stakeholder
Stakeholder is an individual,
team, or organization (or
classes thereof) with interests
in, or concerns relative to, a
system.
Business
Process
A Process that is owned and
carried out by the Business.
A Business Process
contributes to the delivery of
a product or Service to a
Business Customer. For
example, a retailer may have
a purchasing Process that
helps to deliver Services to
its Business Customers.
Many Business Processes
rely on IT Services.
Business
process
Business process is defined as a
behaviour element that groups
a 'flow' of activities, with one
or more clear starting points
and leading to a clearly
defined result, as a defined set
of products or Business
Services.

Business
Service
An IT Service that directly
supports a Business Process,
as opposed to an
Infrastructure Service, which
is used internally by the IT
Service Provider and is not
usually visible to the
Business. The term Business
Service is also used to mean
a Service that is delivered to
Business Customers by
Business Units. For example,
delivery of financial services
to Customers of a bank, or
goods to the Customers of a
retail store. Successful
delivery of Business Services
often depends on one or
more IT Services.
Business
interface
Business interface is defined as
a point of access (logical or
physical) where a Business
Service is made available to
the environment and can be
accessed.
Business
interaction
Business interaction is defined
as a behaviour element that
describes the behaviour of a
business collaboration of two
or more business roles.
Business
service
Business service is defined as a
coherent piece of functionality
(service) that offers added
value to the environment,
fulfilling a business need for a
customer (internal or external
to the organization)
independent of the way this
functionality is realized
internally; Supports business
capabilities through an
explicitly defined interface and
is explicitly governed by an
organization.
Business Unit
Business Unit is a segment of
the Business that has its own
Plans, Metrics, income and
Costs. Each Business Unit
owns Assets and uses these to
create value for Customers
in the form of goods and
Services.
Location
Location is defined as a
conceptual point or extent in
space.
Category
A named group of things
that have something in
common. Categories are
used to group similar things
together. For example, Cost
Types are used to group
similar types of Cost. CI
Types are used to group
similar types of
Configuration Item.
Meaning
Meaning is defined as the
contribution of (the
representation of) a business
object to the knowledge or
expertise of some actor, given
a particular context.
Client
A generic term that means a
Customer, the Business or a
Business Customer.
Stakeholder
Stakeholder is defined as the
role of an individual, team, or
organization (or classes
thereof) with interests in, or
concerns relative to a system
or to the outcome of the
architecture.

G-4
Collaboration
Collaboration services
provide value to the
customer when cooperative
Business Services are
conducted without the
constraints of location or
device.
Business
collaboration
Business collaboration is
defined as an aggregate of two
or more business roles that
work together to perform
collective behaviour
(interactions).
Component
A general term that is used
to mean one part of
something more complex.
For example, a computer
System may be a component
of an IT Service, an
Application may be a
Component of a Release
Unit. Components that need
to be managed should be
Configuration Items.
Device
Device is defined as a
hardware resource upon
which artefacts may be stored
or deployed for execution.
Configuration
Item (CI)
Any Component that needs
to be managed in order to
deliver an IT Service.
Information about each CI
is recorded in a
Configuration Record
within the configuration
management System and is
maintained throughout its
Lifecycle by Configuration
Management. CIs are under
the control of Change
Management. CIs typically
include IT Services,
hardware, software,
buildings, people, and
formal documentation such
as Process documentation
and SLAs.
Data object
Data object is defined as a
coherent, self-contained piece
of information (a passive
element) suitable for
automated processing.
Configuration
Management
Database
(CMDB)
A database used to store
Configuration Records
throughout their Lifecycle.
The configuration
management System
maintains one or more
CMDBs, and each CMDB
stores Attributes of CIs, and
Relationships with other
CIs. System
software
System software represents a
software environment for
specific types of components
and objects that are deployed
on it in the form of artefacts.
Configuration
Management
System (CMS)
A set of tools and databases
that are used to manage an
IT Service Provider's
Configuration data. The
CMS also includes
information about Incidents,
Problems, Known Errors,
Changes and Releases; and
it may contain data about
employees, Suppliers,

locations, Business Units,
Customers and Users. The
CMS includes tools for
collecting, storing,
managing, updating, and
presenting data about all
Configuration Items and
their Relationships. The
CMS is maintained by
configuration management
and is used by all IT Service
Management Processes.
Customer
Someone who buys goods or
Services. The Customer of
an IT Service Provider is the
person or group that defines
and agrees the Service Level
Targets. The term
Customers is also sometimes
informally used to mean
Users, for example 'this is a
Customer-focused
Organization'.
Stakeholder
Stakeholder is an individual,
team, or organization (or
classes thereof) with interests
in, or concerns relative to, a
system.
System
software
System software represents a
software environment for
specific types of components
and objects that are deployed
on it in the form of artefacts.
Dependency
The direct or indirect
reliance of one Process or
Activity on another.
Business
collaboration
Business collaboration is
defined as an aggregate of two
or more business roles that
work together to perform
collective behaviour
(interactions).
Event
Can be defined as a change
of state that has significance
for the management of a
Configuration Item or IT
Service. The term Event is
also used to mean an Alert
or notification created by
any IT Service,
Configuration Item or
Monitoring tool. Events
typically require IT
Operations personnel to take
actions, and often lead to
Incidents being logged.
(Business)
Event
Business event is defined as
something that happens
(internally or externally) and
may influences behaviour
(business processes, functions,
or interactions).
Function
A team or group of people
and the tools they use to
carry out one or more
Processes or Activities. For
example the Service Desk.
The term Function also has
two other meanings: An
intended purpose of a
Configuration Item, Person,
Team, Process, or IT
Service. For example one
Function of an e-mail
Business
function
Business function is defined as
a behaviour element which
offers functionality that may
be useful for one or more
business processes.

G-6
Service may be to store and
forward outgoing mails, one
Function of a Business
Process may be to dispatch
goods to Customers; To
perform the intended
purpose correctly, 'The
computer is Functioning'. _
Infrastructur
e Service
An IT Service that is not
directly used by the Business,
but is required by the IT
Service Provider so they can
provide other IT Services.
For example directory
services, naming services, or
communication services.
Infrastructur
e service
Infrastructure service is
defined as an externally visible
unit of functionality, provided
by one or more nodes,
exposed through well-defined
interfaces, and meaningful to
the environment.
IT
Infrastructur
e
All of the hardware,
software, networks, facilities,
etc. that are required to
develop, Test, deliver,
Monitor, Control or support
IT Services. The term IT
Infrastructure includes all of
the Information Technology
but not the associated
people, Processes and
documentation.
Device
Node
Node is defined as a
computational resource upon
or deployed for execution, i.e.,
represents a structural entity in
the technology layer.
IT Service
A Service provided to one or
more Customers by an IT
Service Provider. An IT
Service is based on the use of
Information Technology
and supports the Customer's
Business Processes. An IT
Service is made up from a
combination of people,
Processes and technology
and should be defined in a
Service Level Agreement.
Infrastructur
e function
Infrastructure function is
defined as a behaviour
element that groups
infrastructural behaviour that
can be performed by a node.
Infrastructur
e interface
Infrastructure interface is
defined as a point of access or
the (logical) location where the
infrastructural services offered
by a node can be accessed by
other nodes or by application
components from the
application layer
Job
Description
A Document that defines the
Roles, responsibilities, skills
and knowledge required by a
particular person. One Job
Description can include
multiple Roles, for example
the Roles of Configuration
Manager and one person
may carry out Change
Business role
Business role is defined as the
responsibility for performing
specific behaviour, to which
an actor can be assigned.

Manager.
IT
Infrastructur
e
All of the hardware,
software, networks, facilities,
etc. that are required to
develop, Test, deliver,
Monitor, Control or support
IT Services. The term IT
Infrastructure includes all of
the Information Technology
but not the associated
people, Processes and
documentation.
Network
Network is defined as the
physical realization of a
communication path, i.e., a
physical communication
medium between two or more
devices.
Communicati
on path
Communication path is
defined as the relation
between two or more nodes,
through which these nodes
can exchange data or
information.
Objective
The defined purpose or aim
of a Process, an Activity or
an Organization as a whole.
mean a Requirement.
Concern
Concern is an interest of a
stakeholder with regards to the
architecture description of
some system, resulting from
the stakeholder's goals, and
the present or future role(s)
played by the system in
relation to these goals.
Procedure
A Document containing
steps that specify how to
achieve an Activity.
Procedures are defined as
part of Processes.
Business
activity
behaviour.
Process
A structured set of Activities
designed to accomplish a
specific Objective. A Process
takes one or more defined
inputs and turns them into
defined outputs. A Process
may include any of the
Roles, responsibilities, tools
and management Controls
required to reliably deliver
the outputs. A Process may
define Policies, Standards,
Guidelines, Activities, and
Work Instructions if they are
needed.
Business
process
Business process is defined as a
behaviour element that groups
a 'flow' of activities, with one
or more clear starting points
and leading to a clearly
defined result, as a defined set
of products or Business
Services.
Requirement
Is a formal statement of
what is needed as for a
service level requirement, a
project requirement or the
required deliverables for a
process.
Business
activity
behaviour.
Role
A set of responsibilities,
Activities and authorities
granted to a person or team.
A Role is defined in a
Process. One person or team
Business role

G-8
may have multiple Roles; for
example, a single person
may carry out the Roles of
Configuration Manager and
Change Manager.
Business
actor
Business actor is an
organizational active entity
that is capable of performing
behaviour (i.e., the 'subject' of
behaviour).
Server
A computer that is
connected to a network and
provides software Functions
that are used by other
Computers.
Device
Service
A means of delivering value
to Customers by facilitating
Outcomes Customers want
to achieve without the
ownership of specific Costs
and Risks.
Product
Product is defined as a
coherent collection of services,
accompanied by a
contract/set of agreements
that specifies the
characteristics, rights, and
requirements for their use,
which is offered as a whole to
(internal or external)
customers.
Service
Service is defined as a unit of
functionality that a system
exposes to its environment,
while hiding internal
operations, which provides a
certain value (monetary or
otherwise).
Contract
A legally binding Agreement
between two or more
parties.
Contract
Contract is defined as a formal
or informal specification of an
agreement that specifies the
rights and obligations
associated with a product.
Operational
Level
Agreement
(OLA)
Operational Level
Agreement is an Agreement
between an IT Service
Provider and another part of
the same Organization. An
OLA supports the IT
Service Provider's delivery of
IT Services to Customers.
The OLA defines the goods
or Services to be provided
and the responsibilities of
both parties. For example
there could be an OLA:
Between the IT Service
Provider and a procurement
department to obtain
hardware in agreed times;
Between the Service Desk
and a Support Group to
provide Incident Resolution
in agreed times.
Service
Contract
A Contract to deliver one or
more IT Services. The term
Service Contract is also used
to mean any Agreement to

deliver IT Services, whether
this is a legal Contract or an
SLA.
Service Level
Agreement
(SLA)
An Agreement between an
IT Service Provider and a
Customer. The SLA
describes the IT Service,
documents Service Level
Targets, and specifies the
responsibilities of the IT
Service Provider and the
Customer. A single SLA
may cover multiple IT
Services or multiple
customers.
Underpinning
Contract (UC)
Is a Contract between an IT
Service Provider and a
Third Party. The Third
Party provides goods or
Services that support
delivery of an IT Service to a
Customer. The
Underpinning Contract
defines targets and
responsibilities that are
required to meet agreed
Service Level Targets in an
SLA.
Service
Owner
Service Owner is a Role that
is accountable for the
delivery of a specific IT
Service
Business role
Service
Portfolio
The complete set of Services
that are managed by a
Service Provider. The
Service Portfolio is used to
manage the entire Lifecycle
of all Services, and includes
three Categories: Service
Pipeline (proposed or in
Development); Service
Catalogue (Live or available
for Deployment); and
Retired Services.
Product
Product is defined as a
coherent collection of services,
accompanied by a
contract/set of agreements
that specifies the
characteristics, rights, and
requirements for their use,
which is offered as a whole to
(internal or external)
customers.
System
A number of related things
that work together to
achieve an overall Objective.
For example: A computer
System, including hardware,
software and Applications; A
management System,
including multiple Processes
that are planned and
managed together. For
example, a Quality
Management System; A
Database Management
System or Operating System
that includes many software
Device

G-10
modules that are designed to
perform a set of related
Functions.
User
A person who uses the IT
Service on a day-to-day
basis. Users are distinct from
Customers, as some
Customers do not use the IT
Service directly.
Business
actor
Business actor is an
organizational active entity
that is capable of performing
behaviour (i.e., the 'subject' of
behaviour).
Value
Value is something
intangible such a service
defined in terms of
customer’s business
outcomes. Value is the result
of two key elements: utility
or what the customer
perceives from the attributes
of the service; and warranty
is how the service delivered
or the positive effect of the
service being available when
needed.
Value
Value is defined as the relative
worth, utility, or importance
of a Business Service or
product that makes some
party appreciate it (product or
service).
Driver
Something that influences
Strategy, Objectives or
Requirements. For example,
new legislation or the actions
of competitors.
Driver
Driver is defined as something
that creates, motivates, and
fuels the change in an
organization.
Assessment
Inspection and analysis to
check whether a Standard or
set of Guidelines is being
followed, that Records are
accurate, or that Efficiency
and Effectiveness targets are
being met. See also Audit
Assessment
Assessment is defined as the
outcome of some analysis of
some driver.
Objective
The defined purpose or aim
of a Process, an Activity or
an Organization as a whole.
mean a Requirement.
Goal
Goal is defined as an end state
that a stakeholder intends to
achieve.
Requirement
Is a formal statement of
what is needed as for a
service level requirement, a
project requirement or the
required deliverables for a
process.
Requirement
Requirement is defined as a
statement of need that must be
realized by a system.

Critical
Success
Factor (CSF)
A Critical Success Factor is
something that must happen
if a Process, Project, Plan, or
IT Service is to succeed.
KPIs are used to measure
the achievement of each
CSF. For example a CSF of
'protect IT Services when
making Changes' could be
measured by KPI
Constraint
Constraint is defined as a
restriction on the way in which
a system is realized.
Specification
A formal definition of what
is needed. A specification
may be used to define
technical or operational
requirements, and may be
internal or external.
Principle
Principle is defined as a
normative property of all
systems in a given context, or
the way in which they are
realized.
Representatio
n
Representation is defined as a
perceptible form of the
information carried by a
business object, such as a
document.

Appendix H – IMAGES FROM THE FIELD STUDY
Previous Project
Figure 117 – Process Using BPMN
Figure 118 –BPMN’s Change Management

H-2
Figure 119 – Model of the Communications Area (ATACS)
Figure 120 – Model of the Communications Area (ATACS)

Figure 121 – Model of the Administration Systems Technical Area (ATAOS)
Figure 122 – Relationships Between Concepts in the EA

H-4
Current Project
NOTE: Some figures are intentionally illegible due to confidentiality issues.
Figure 123 – Sample of Service Catalogue
Figure 124 – Sample of Clusters

Figure 125 – Sample of Applications
Figure 126 – Sample of Process
Figure 127 – Sample of Actors

H-6
Figure 128 – Sample of Organization Chart
Figure 129 – Sample of Racks

Figure 130 – Sample of Servers
Figure 131 – Sample of Databases

H-8
Figure 132 – Sample of Networks

Thesis Nelson Gama - Integrating EA and ITSM

Thesis Nelson Gama - Integrating EA and ITSM

More Related Content

Featured

Thesis Nelson Gama - Integrating EA and ITSM