1. 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
2.
3.
4.
5. 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
6.
7. 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.
8.
9. 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.
10.
11. 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…
12.
13. 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...
14.
15. 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!
16. 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!
17. 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!
18. 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!
19. 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!
21. 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!
22. 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!
23. 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!
24. 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!
25. 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!
27. 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
28. 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
29. 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).
30. 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).
31. 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
32. 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
33. 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.
34. 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,
35. 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?
36. 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
37. 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.
38. 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
39. 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.
Define
properties
Enumerate
terms
Create
concepts
Define
relations
40. 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.
41. 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
Verification
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
42. 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.
43. 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.
44. 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:
45. 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).
46. 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.
47. 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).
48. 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).
49. 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].
50. 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
www.via-nova-architectura.org March 2007 5
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.
51. 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.
52. 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
53. 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
54. 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
55. 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.
56. 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 specification,
leading to an inconsistent interpretation and use of knowledge underlying the
terminology of enterprise models (Grüninger, Atefi, & Fox, 2000).
57. 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.
