Using Maturity Models in ArchiMate for Implementing ITIL

Using Maturity Models in ArchiMate for Implementing ITIL 64823 - Nuno Silva nuno.miguel@ist.utl.pt Advisor: Prof. Miguel Mira da Silva Co-Advisor: Prof. Pedro Sousa Departamento de Informática Instituto Superior Técnico Abstract. The IT Infrastructure Library (ITIL) is the de facto standard for implementing IT Service Management inside organizations. It uses methods and practices that describe how a service should be managed in order to achieve maximum efficiency and effectiveness. However most organizations struggle with its implementation and that leads to a waste of resources, high costs and effort. There have been studies and research works that have proposed maturity models for ITIL with the purpose of facilitating the implementation of ITIL inside organizations. Nowadays, organizations need to specify the components and its relationships used to manage and align assets, people, operations and projects that support business goals and strategies concerning them. That is the main goal of Enterprise Architecture (EA) and of the EA modeling language ArchiMate. By connecting both the ITIL and EA approaches with ITIL maturity models, organizations could ease their efforts in implementing ITIL and maximize the overall costs and resources, therefore becoming more mature, effective and efficient. Our goal is to use these ITIL maturity models (focusing on a specific one) in ArchiMate for implementing ITIL inside organizations. The demonstration of this work will be its application on a field study at Hospital Santa Maria IT Department focusing on the ITIL Incident Management process. For evaluating our proposal we shall evaluate our demonstration, use interviews, the Moody and Shanks framework, and the Wand and Weber ontological method. Keywords: IT Service Management, ITIL, Enterprise Architecture, ArchiMate, Maturity Model, TIPA, metamodel 1 Introduction Throughout the years, IT suffered a transformation from being a traditional orientation of administrative support to a strategic role where business and IT posed a major concern [1]. The Henderson’s strategic alignment model presented several perspectives on how to integrate the business and IT domains, proposing concepts like information systems service organizations and IT governance [2]. Focusing on the IT Governance, more specifically, on the IT alignment, two approaches have had major relevance: IT Service Management (ITSM) and Enterprise Architecture (EA) [1]. IT Service Management (ITSM) evolved naturally as services became underpinned in time by the developing technology. In its early years, IT was mainly focused on application development, but as time went by, new technologies meant concentrating on delivering the created applications as a part of a larger service offering, supporting the business itself [3]. ITIL [4] is the de facto standard for implementing ITSM [5]. It is a practical, nononsense approach to the identification, planning, delivery and support of IT services to the business [6]. The ITIL Core consists of five publications: Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. Each book covers a phase from the Service Lifecycle and encompasses various processes which are always described in detail in the book in which they find their key application [7]. Enterprise Architecture (EA) is a coherent whole of principles, methods, and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems, and infrastructure [8]. More than 100 IT management maturity models have been proposed since 1973. Nonetheless, due to the generality of most of them, they are neither well defined nor documented. The Process Maturity Framework (PMF) is the only maturity model specifically proposed for ITIL v2. Nevertheless it only consists of 6 pages which is unthinkable to even considering using this model for evaluation and implementation purposes concerning ITIL inside organizations [18]. TIPA, [9] (Tudor’s ITSM Process Assessment) is the result of 8 years of research work, including experimentation on combining ITIL with the ISO/IEC 15504 (Process Assessment Standard) that resulted in a framework to measure maturity levels of organizations based on ITIL. TIPA is a standards-based approach to ITIL (“v3”) assessment that can address the challenges (posed by improving the quality of product manufacture or of IT processes) in several important ways, by providing a repeatable, consistent method for conducting process assessment [9]. Many organizations have tried to implement ITIL. However, most of them tend to struggle with its implementation due to organizational challenges such as staff resistance to change, task conflicts and ambiguous orders leading to high efforts and costs [30]. ITIL Maturity Models like the one proposed by Pereira [18] or TIPA [9] are frameworks that, if used correctly and well understood, can help organizations in successfully and correctly implementing ITIL. Hence, our proposal is to use an instantiation of an ITIL Maturity model in ArchiMate to help organizations implement ITIL. Roughly speaking, we propose the creation of an ITIL Maturity Model metamodel in ArchiMate. With the implementation of this metamodel, we plan to establish the bridge between the EA elements of an organization and Vicente’s ITIL representation in ArchiMate [1] as means of representing maturity levels in and Enterprise Architecture directly and also to help 2 reducing the effort, costs and resource expenses due to ITIL implementation inside organizations. To demonstrate our proposal we will be doing a field study which will be held at the IT Department of the Santa Maria Hospital in Lisbon, Portugal where we’ll use Link Consulting’s EA tool - EAMS to implement our proposal and validating it with the help of the IT Department’s EA and Vicente’s ITIL representation in ArchiMate. For validation purposes, we will be focusing on representing the ITIL Incident Management, mainly because it is a process that is always present in all IT Departments and therefore, from all the ITIL processes, this would be the most interesting to represent. The evaluation of our proposal will consist of the evaluation of our demonstration, interviews to experts in the area such as ITIL Certified Experts and the IT Department’s Director and Staff in order to evaluate and validate our proposal as well as the use of the Moody and Shanks framework [10] for model quality management and the Wand and Weber [28] ontological analysis method to evaluate our concept mappings from our maturity model elements to ArchiMate’s. The following sections of this report follow the six steps of Design Science Research Methodology explained in the next section. The Research Problem and Related Work sections cover aims and objectives regarding the awareness and recognition of a nonspecific problem from a state of the art review that brings us important issues that must be addressed. Afterwards, the Research Proposal section presents a proposal as an attempt to solve the previously defined problem. Next the Demonstration section describes how the proposal will be put into practice and also a brief description of the work already done regarding the problem’s solution. We finish this project report with the Evaluation section comparing the results with the research questions and describing the conclusions in the Conclusions section. 2 Research Methodology The methodology to be applied across this thesis is Design Science Research (DSRM) where we develop and validate a proposal to solve our problem [11]. It is an iterative research process composed of six steps: problem identification and motivation, definition of the objectives for a solution, design and development, demonstration, evaluation, and communication [12]. Its goal is to overcome standard research methodologies, such as traditional descriptive research and interpretative research, whose research outputs are mostly explanatory and, arguably, not often applicable to the solution of problems encountered in research and practice [12]. DSRM accomplishes this by designing and creating an explicitly applicable solution to a problem, being an accepted research paradigm in the area of engineering [12]. Information Systems is considered an applied research discipline where we often apply theory from other disciples, such as economics, computer science, social 3 A field study (IT Dept. at Santa Maria Hospital) where we shall use an EA tool to validate our proposal Evaluation a) Demonstration of the Proposal b) Interviews to experts in the area c) Wand and Weber ontological method Disciplinary Knowledge Representation of an ITIL maturity model in ArchiMate (TIPA Metamodel) Demonstration Metrics, Analysis, Knowledge Design & Development How to knowledge How to ease the effort of implementing ITIL in organizations? Define objectives of a solution Provide easier alternatives to use ITIL maturity models in ITIL implementation inside organizations by means of their EA Theory Identify problem & motivate Inference sciences, among others, in order to solve problems at the intersection of IT and organizations [12]. The integration of design as a major component of research has been successfully accomplished by several researchers with the goal of solving relevant organization problems [12]. Communication Use this thesis and publish one or more articles to communicate the artefacts, its value and utility d) Moodys and Shanks framework Fig. 1. The DSRM process (adapted from [12]) DSRM proposes the design and development followed by a demonstration and evaluation of artifacts that may include constructs (vocabulary and symbols), models (abstractions and representations), methods (algorithms and practices) and instantiations (implemented and prototype systems) [11]. The main focus of this thesis will be in the creation of a model and an instantiation of that model. In Fig. 1 we map the DSRM steps to our work. The following chapters follow the methodology's steps those being: "Problem Identification" and "Related Work" whose aim is to raise recognition and awareness of a problem from a state of the art review giving us the main issues that must be addressed. Following, "Proposal" presents an attempt to solve the previously described problem. Afterwards, we present a "Demonstration" that is followed by the "Evaluation" where we compare the results obtained by designing, implementing and applying our solution to the research questions, concluding with our proposal applicability and themes for future work. 3 Research Problem This section describes the “Identify problem & motivate” step of the DSRM process, where we come to realize and recognize a problem from a state of the art review, giving us issues that require our attention and must be addressed. Organizations nowadays tend to become more and more service-oriented towards their clients. IT frameworks offer a set of best practices for better efficiency, 4 effectiveness and maturity of their business and are constantly addressed in the area of IT Service Management. There is no doubt that the ITIL framework is ITSM’s de facto standard and these companies usually struggle with its implementation due to organizational challenges such as staff resistance, task conflicts and ambiguous orders that lead to high efforts and costs [30]. Many organizations already tried to implement ITIL; however, they came up with a set of practical issues that caused that implementation to fail. Those reasons [30] were: 1. Lack of management commitment: without management commitment we can only hopefully achieve isolated wins that will be few and far between. 2. Spending too much time on complicated process diagrams: in the first steps of ITIL implementation there is a great temptation of producing complex process maps. Nevertheless, for most processes they are unnecessary and result in wastes of time and resources. 3. Not creating work instructions: Some organizations fail to establish written work and therefore, the creation of complex process maps is futile. It is better to have written, published and continually reviewed work instructions. 4. Not assigning process owners: Most of the IT departments are silo-based but not ITIL. ITIL is process-based so, a process owner should be assigned to each ITIL process that crosses those silos. The owners should have a complete process vision and monitoring and not worry about staffing or other departmental issues. 5. Concentrating too much on performance: Organizations focus too much on achieving best performance and ignore the importance of quality and processes. 6. Being too ambitious: Organizations attempt to implement all the ITIL processes at once and it causes confusion, staff unrest, and poor integration between the processes. 7. Failing to maintain momentum: The estimated period for ITIL implementation is three to five years and demands a huge effort to implement all of its processes in the target organization. The implementation process should be continuous and even if the rewards of ITIL come in early stages, the organizations should not lose the momentum. 8. Allowing departmental demarcation: Some of the ITIL processes are cross departments and that sometimes generates conflicts, especially when there are rigid department boundaries. 9. Ignoring solutions other than ITIL: ITIL is not the holy grail of ITSM. It is the de facto standard of ITSM but sometimes organizations need to adapt to other frameworks in order to achieve their needs like ISO 20000 or COBIT. 10. Ignoring reviewing of the ITIL every time: Implementing ITIL is very important but only if the best practices are maintained in the organizations. Audit is therefore very important in the organization from time to time. 11. Not memorizing ITIL books self: ITIL cannot be implemented with some paper based instructions without any attend to target organization. It can only 5 be successfully implemented by understanding how those best practices apply, based on target organization’s IT strengths and abilities. After understanding all the practical problems organizations face nowadays in implementing ITIL, we should look to the other side of the coin: how organizations represent themselves, their elements and relations amongst them. As Vicente says in is work, EA principles remain the best way to represent organizations as a system, by relating multiple architectures to their artifacts and components, the scope of ITIL also involves those architectures but it does not describe how to design and realize the whole organization [1]. We concluded from Vicente’s work that EA and ITIL are strongly related and therefore we believe that within this relation lies a solution to help reducing the efforts and costs, as well as eliminating all the above practical problems of ITIL implementation. This approach could then lead the organizations to achieve better maturity, efficiency and effectiveness of their businesses. From all the attempts in relating maturity models and ITIL, Tudor [9] excelled in approaching the relations between Process Assessment and ITIL to provide a framework of Process Assessment in an 8-year research work called TIPA that describes how to increase the maturity level of organizations processes and make them compliant with ITIL. Nevertheless, those metrics are extensively documented and can lead once again to the practical problem of emphasizing paper instructions too much. Furthermore, TIPA does not relate its criteria to how the EA of the organization should adapt in order to achieve compliance with ITIL (which would be a more interesting approach for companies to fully comprehend what changes need to be done). Fig. 2 illustrates our problem. Organization Resources Costs Time Effort Fig. 2. Difficulty in ITIL implementation inside organizations 6 All things considered, we define our problem as the difficulty in implementing ITIL inside organizations with less costs, effort, time and resources. 4 Related Work In this section we present a literature review of the main concepts and areas of research related to this project. We start by introducing the IT Infrastructure Library (ITIL), a best practice model to IT Service Management. Afterwards, we will present the work that has been done regarding ITL Maturity Models showing as main examples Pereira’s ITIL Maturity Model and the ISO/IEC 15504 (Process Assessment Standard) by the Public Research Center Henri Tudor that culminated in internationally-recognized framework for IT process assessment known as TIPA. In the third part of the Related Work section we will describe the concepts of Enterprise Architecture (EA), a framework that is used worldwide that represents organizations and also the standard modeling language that provides a uniform representation of the organization’s EA as well as its motivation extension finishing with Vicente’s work of representing ITIL in ArchiMate. Finally, we conclude the Related Work section with a brief summary explaining why none of these researches solve our research problem. 4.1 ITIL Enterprises need to manage the delivery of services that support users in conducting their activities in the context of business processes [13]. ITIL was created by the Central Computer and Telecommunications Agency (CCTA), an office of the British government and was first released to the public in the late eighties [14]. ITIL is a common-practice model possessing the character of a branch standard [15]. While the first version was mainly based on experience in data centers running big mainframes, in 2000 a revised version (ITIL v2) was launched becoming the worldwide de facto standard for IT Service Management [14]. In 2007, ITIL V3 introduced the lifecycle principle, whereby the provisioning of services was considered to be a continuous process in which new services are brought into existence whilst others are phased out [14]. The current version of ITIL covers the major weaknesses identified in the previous versions, namely being too focused on technology [16]. Now, instead of focusing on the service itself, the focus lay on this cycle of life, renewal and decommissioning of services, with a greater businessfocused perspective [14]. The ITIL Core consists of five publications: Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. Each book covers a phase from the Service Lifecycle with 7 various processes which are always described in detail in the book in which they find their key application [17]. Now, instead of focusing on the service itself, the focus lay on this cycle of life, renewal and decommissioning of services, with a greater business-focused perspective [14]. The ITIL Core consists of five publications: Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. Each book covers a phase from the Service Lifecycle with various processes which are always described in detail in the book in which they find their key application [7]. 4.2 Maturity Models Maturity Models are important in establishing high levels, goals and practices in the organizational world. Some of those models are mainly focused on services (CMMI for Services, ITSCMM), others on software (CMM, Trillium, Bootstrap) and there are others that focus on ITIL (PMF, Pereira’s ITIL Maturity Model and TIPA) [35]. However, since our thesis focus is ITIL, we shall discuss in the next sections the two main ITIL approaches concerning Maturity Models: Pereira’s ITIL Maturity Model and TIPA. Pereira’s ITIL Maturity Model. As far as existing Maturity Models for ITIL are concerned, Pereira [18] proposed a CMMI-based ITIL Maturity Model as a better option to the existing Process Maturity Framework (PMF) specifically designed for ITIL v2. He defined maturity levels for the Stage Model and for the Continuous Model, taking into consideration the chosen model and the context of ITIL, and also the relation between the Stage Model and the Continuous Model [18]. For the Continuous Model (better for organizations that already know which processes want to implement and/or evaluate), he defined 5 levels of maturity and used a questionnaire for process evaluation purposes composed of previously validated ITSCMM and CMMI-SVC factors. However, he only had a questionnaire for the ITIL’s Incident Management Process. Nevertheless, that questionnaire was used and tested, as means of evaluating the process, in two Portuguese organizations [18]. For the Stage Model (better for organizations that don’t know where to start regarding ITIL implementation), he also defined 5 levels of maturity. The attribution of a level of maturity to an ITIL process was done based on the compatibility between the processes purpose and the description of the Stage Model’s maturity levels. For example, the Incident Management Process is related with customer’s satisfaction therefore, is grouped in level 2, whereas Service Measurement or Knowledge Management are related with information management and how it is measurement so 8 the go to Stage Management’s maturity level 4. The same line of thought is applied to the remaining processes [18]. By relating both Models, Pereira concluded that they are not completely independents of one another. When an organization follows the Continuous Model is because it already knows which processes are to be implemented or evaluated. However, if the organization does not know which processes to implement first, they will probably follow the Stage Model to know it. Concluding, an organization that wants to start implementing ITIL, by following Pereira’s Maturity Model, will start by using the Stage Model and then the Continuous Model to evaluate and/or implement the processes [18]. Fig. 3 illustrates Pereira’s Maturity Model. Fig. 3. Pereira’s Maturity Model (from [18]) TIPA. Although Pereira’s work [18] proved to have some pros, such as being extremely necessary given the reality of ITIL’s implementation worldwide, less error prone in implementing ITIL correctly in the organizations and giving the organizations the knowledge of where they are and what they need to do to achieve full maturity, effectiveness and efficiency, it is nevertheless a master’s thesis and therefore, does not have the financial and timing effort of a real research theme. TIPA (Tudor’s ITSM Process Assessment) is the result of 8 years of research work, including experimentation on combining ITIL with the ISO/IEC 15504 (Process Assessment Standard). TIPA is a standard ds-based approach to ITIL (“v3”) assessment that can address the challenges (posed by improving the quality of product manufacture or of IT processes) in several important ways, by providing a repeatable, 9 consistent method for conducting process assessment [9]. Fig. 4 illustrates the Process Assessment Model that maps the base practices of ITIL v3 with the generic practices of ISO 15504. PROCESS ASSESSMENT MODEL Base Practices: Generic Practices: INC.BP1: Define and agree on incident categories and priorities (…) INC.BP1: Define, agree and communicate timescales for all incident-handling stages. (..) INC.BP3: Detect and log the incidents (…) … GP 2.1.1 Identify process performance objectives GP 2.2.2 Plan and monitor process performance GP 2.1.3 Adjust performance of the process to meet plans GP 2.1.4 Define responsibilities and authorities for performing the process … Process performance indicators Process capability indicators Work Products Inputs/Outputs Generic Work Products Generic Resources Process Dimension Capability Dimension ITIL v3 ISO 15504 Process Reference Model Process Capability Levels Fig. 4. TIPA’s Process Assessment Model (from [9]) A TIPA assessment provides more than just a simple determination of process maturity. It pinpoints the current level of maturity a given process has achieved and calls out specific deficiencies which, if corrected, would advance the process to achievement of the desired level of maturity [9]. When doing a TIPA assessment, a baseline assessment is conducted to get a very clear, objective understanding of where the organization is right now as basis for sound improvement planning [9]. During the entire process confidentiality is a key point in obtaining accurate insightful information regarding the organization. The results of the baseline assessment are used to create a roadmap for improvements, which are driven forward by properly prepared process leaders. The skills to monitor and improve specific processes are easily acquired [9]. Fig. 5 shows us the Assessment progression of a TIPA assessor. 10 Baseline TIPA Assessment Performed by objective Improvements based on assessment external assessors. Train enterprise assessors Performed on select high-value processes. Results used to plan improvements. Improvements implemented as identified from baseline assessment. Meanwhile, suitable internal assessors are identified and trained. (candidates should be ITIL Experts and then trained in TIPA assessment techniques) Follow-up assessments Alternating internal and external assessments. Identify next improvements and implement. Re-baseline every two years. Fig. 5. TIPA’s Assessment Progression (from [9]) The process improvement is an approach that is time consuming and can take a great amount of time mainly because there are many inter-dependencies between the ITIL processes. For example, change assessment (part of the change management) relies on accurate configuration data, and accurate configuration data is heavily influenced by clearly defined services, etc. So it can be very difficult to increase process maturity in one process if a related process is missing key elements [9]. Another challenge to process improvement is that organizations are often fragmented, with multiple service provider types within the IT organization each with selfcontained processes. Viewed independently, there could conceivably be relatively high levels of process capability and maturity. But the business usually views IT as a single entity, which often calls for a standard set of ITSM processes across the organization [9]. Fig. 6 illustrates the maturity level hierarchy from both the Instance and the Organization views. 11 Fig. 6. TIPA’s Maturity Level Hierarchy (from [9]) The goal of any organization that relies in these assessments is to obtain the top maturity level possible, therefore, in a perfect world each process would be at level 5 of maturity. After all, one of the primary goals of ITSM is to continually improve the quality of service delivered and mature processes should help ensure service quality. Realistically, however, this may not always align with business priorities. Improvement might be defined as doing more with less, continuously leading by innovation, or any other definition that best addresses the needs of the enterprise. Business-driven decision-making and strategy definition is the key [9]. Achieving operational excellence and ultimately distinctive performance will require effective and efficient process across the service lifecycle. A standards-based approach to assessing process maturity can provide a repeatable, vendor natural, and structured approach to assessment. The results will include return on IT investments, less re-work as a result of improved prioritization of improvement initiatives, and cost reduction as processes mature based on business drivers [9]. 4.3 Enterprise Architecture The Zachman Framework [19] appeared in the late 1980s with the goal of defining logical constructs (architectures) to represent organizations. It is based on the principle that an organization doesn’t have just one architecture, but a set of them, arranged as layers. Each of these layers produce artifacts that answer six organizational questions (What, Where, When, Why, Who, How) [19]. 12 Today, business performance depends on a balanced and integrated design of the enterprise, involving people, their competencies, organizational structures, business processes, IT, finances, products, and services, as well as its environment [20]. EA is a coherent set of principles, involving the design and performance of different architectures. It specifies the components and its relationship, which are used to manage and align assets, people, operations and projects to support business goals and strategies [8][21], concerning those properties of an enterprise that are necessary and sufficient to meet its essential requirements [20]. EA is based on a holistic representation of organizations, on views and the ability to map relationship between artifacts, and on the independence and connection between artifacts and architectures, and on the independence and connection between layered architectures [22] which usually are [8][19]: Business, Process, Application, Information, and Technology. The alignment between architectures allows a coherent blueprint of the organization, which is then used for governance of its processes and systems [23]. ArchiMate. The ArchiMate EA modeling language was developed to provide a uniform representation for architecture descriptions [24][25]. It offers an integrated architecture approach that describes and visualizes the different architecture domains and their underlying relationships and dependencies [24][25]. The goal of the ArchiMate project is to provide domain integration through an architecture language and visualization techniques that picture these domains and their relations, providing the architect with instruments that support and improve the architecture process [26]. In a short time, ArchiMate has become the open standard for architecture modeling in the Netherlands; it is now also becoming well known in the international EA community, being today a TOG standard [24]. The domains of business, application and infrastructure are connected by a service orientation paradigm, where each layer exposes functionality in the form of a service to the layer above [17]. Besides this, it also distinguishes between active structure, behavior and passive structure elements, having also another distinction between internal and external system view. On top of this, ArchiMate is a formal visual design language, supports different viewpoints for selected stakeholders and is flexible enough to be easily extended [17]. Fig. 7 illustrates the ArchiMate generic metamodel, consisting of its core concepts and respective relations. 13 Fig. 7. Generic Metamodel: The Core Concepts of ArchiMate (from [31]) ArchiMate Motivation Extension. Motivational concepts are used to model the motivations, or reasons, that underlie the design or change of some enterprise architecture. These motivations influence, guide, and constrain the design [31]. Fig. 8 illustrates the ArchiMate Motivation Extension Metamodel. Fig. 8. The ArchiMate Motivation Extension Metamodel (from [31]) In this figure we have the ArchiMate Motivation Extension concepts and how they related with each other. Drivers are factors that influence the motivational elements and their source can be from either outside or inside the organization. The internal drivers (concerns) are associated with another motivational concept: stakeholder. Stakeholders can either be an individual or a group of human beings like a project 14 team, an enterprise or a society [31]. Organizations usually undertake an assessment of these drivers to decide whether existing intentions need to be adjusted or not. The actual motivational concepts are represented by goals, principles, requirements, and constraints. Goals represent a desired result, or end that a stakeholder wants to achieve. Principles and requirements represent desired properties of solutions or means to realize the above said goals. Principles are normative guidelines that guide the design of all possible solutions in a given context, whereas requirements represent formal statements of need, expressed by stakeholders that must be met by the architecture or solutions [31]. ITIL in ArchiMate. Vicente approached the concept of integrating EA and ITIL and went more far than anyone else in this area by successfully defining an EA specification in ArchiMate that uses ITIL principles, methods, processes and concepts to perform IT Service Management, and general EA principles, methods and models to the design and realization of the remaining organizational structure [3]. Vicente had already defined this architecture’s motivation model, its drivers, assessments, goals, requirements and principles [27], and so he would continue his work on representing the architecture, on modeling ITIL components and relationships according to the EA approach and the ITIL principles, constraining the organization’s freedom of design [3]. One of the problems that Vicente noticed was the fact that having two different frameworks to approach governance can lead to several setbacks. In a time when organizations strive to be efficient and effective, it seems counterintuitive to be wasting resources by having different organizational departments or teams handling both approaches independently. In fact, while enterprise architects are designing organizations based on EA principles and trying to align business and information systems, its IT departments are using ITIL to design and manage IT services. This is being done in closed silos, where the architect knows little about how ITIL is being used on the IT departments, increasing the gap between business and IT, strategy and functional integration [1]. Vicente had also realized from his research that because ITIL content is based on natural language descriptions, it lacks a formal notation and representation, what sometimes led to different interpretations and discussion between practitioners. Therefore, besides his work of integrating EA and ITIL aims to enhance ITIL with a formal representation of concepts for knowledge sharing, stakeholder communication and to aid discussion and validation by the ITIL community itself [3]. This approach, as Vicente demonstrates, has the goal of giving the architect the elements and models to design specific organizations according to best practices, which in this case is ITIL and ITSM [3] and could also become a tool to check for compliance and maturity levels in particular organizations [3]. Fig. 9 illustrates Vicente’s proposal. 15 Fig. 9. Vicente’s Proposed Enterprise Architecture (from [1]) 4.4 Summary The state-of-the-art brings high contributions to the organizational scenario, but none of them provide a solution to our problem of implementing ITIL in organizations and therefore, the practical problems of its implementation still remains. All organizations are composed by a set of elements and relations between those elements that are represented in an Enterprise Architecture with the use of the ArchiMate standard. But the Enterprise Architecture AS-IS cannot relate the organizational changes that can be represented through that same EA with ITIL. 5 Research Proposal In this section, by taking the research problem described above into consideration, we propose using Maturity Models in ArchiMate for implementing ITIL. Throughout this section we will focus on two important steps. In the first one, we will describe the objectives of our solution. In the second step, we will briefly explain how the model will be conceptualized and which knowledge and approaches we will use. This sections correspond to the “Define objectives of a solution” (where we define our goal as a method of facilitating the implementation of ITIL on ITSM-based organizations using a framework of an ITIL Maturity Model instantiation and relating it the organization’s Enterprise Architecture) and to the “Design and Development” (where we present the process of designing and developing the ITIL Maturity Model metamodel) steps of the DSRM process. 16 5.1 Objectives of the Solution As we have seen, being compliant with ITIL provides a high organizational maturity, effectiveness and efficiency inside any IT-driven organization. Therefore, by modeling ITIL maturity in ArchiMate we are targeting two main goals. First, taking advantage of the organization’s EA as a way of facilitating ITIL implementation and as a way of proving the strong connection between EA and ITIL like Vicente did in his work. Second, by having an ArchiMate representation of the ITIL Maturity Model, we want to reduce the efforts, time, resources and costs of ITIL implementation. With that said, our main objective is to check for ITIL compliance inside organizations but mainly to help organizations achieve in an incremental way effectiveness, efficiency and maturity by implementing ITIL with reduced efforts, time, resources and costs. 5.2 Design and Development As mentioned before, TIPA represents a maturity model for ITIL based on the ISO/IEC 15504 (Process Assessment Standard) and for purposes of designing and developing our proposal we shall use it as an instantiation of our ITIL maturity model. Fig. 10 illustrates our proposal. ISSO 15504 TIPA Metamodel ArchiMate ITIL Fig. 10. TIPA metamodel in ArchiMate for help in ITIL implementation 17 Figure 10 is divided into 3 main layers: the ISO 15504 layer, the TIPA layer which is an instantiation of the ISO 15504 and finally the ITIL/ArchiMate layer where we connect both approaches with our proposed TIPA metamodel. This figure also illustrates in a top-down approach the sequence of steps that we are going to do throughout the design and development of our proposal. We will first take into consideration the ISO 15504 and more specifically the TIPA core concepts and their relations that shall serve then as input for the creation of our TIPA metamodel in ArchiMate. With that said and to address the above mentioned objectives we will define the development of our proposal in four basic steps. 1. 2. 3. 4. In order to model any kind of universe, we must know which the elements that compose that same universe are. Therefore, as first step, we will identify all the concepts that define TIPA. After identifying the TIPA concepts we need to acknowledge the fact of whether or not those concepts are already possible of being modeled with the existing ArchiMate concepts. In other words, we will need to create a semantic mapping between the TIPA concepts and the ArchiMate’s ones. After concluding the mapping we can come to the conclusion that there are no existing ArchiMate elements that can represent every TIPA concept. That should not be the case since TIPA’s criteria nature relates with the Business Motivation Model and ArchiMate already possesses an extension of it. Although, if that scenario happens we need to propose a new ArchiMate extension where we create new elements and relations between them that will represent the TIPA concepts that cannot be supported by the current ArchiMate version. The final step will be the creation of a TIPA metamodel in ArchiMate that can clearly represent all the TIPA elements and relations amongst them. There has been some work concerning the representation of frameworks and concepts in ArchiMate like the capture of business strategy and value in EA [32][33], the representation of KPIs in ArchiMate [34] and even Vicente’s work of representing ITIL in ArchiMate [1]. 6 Demonstration This section describes the “Demonstration” step of the DSRM method, where we demonstrate all the work done concerning our proposal. This section will be divided in 2 main subsections: The work already done and the one yet to be done described in the TIPA in EAMS section. 18 In the Work Done section, we will describe the work that has been done related to the implementation of our proposal in Link Consulting’s EA tool - EAMS. That section is divided in 2 sections: the implementation of Vicente’s work [1] in EAMS and the surveys that have been done inside the IT Department of Santa Maria Hospital with the purpose of modeling its EA. In the TIPA in EAMS section we will describe the steps that are going to be done in the next phase of our thesis in order to conclude our demonstration process. 6.1 Work Done This section is divided in two sections where we explain the work that has been done for demonstration and validation purposes of our proposal. In the Implementation of Vicente’s Work we explain all the process of implementing Vicente’s proposal inside the EAMS EA tool. In the IT Department’s Enterprise Architecture section we describe the process of collecting information about Santa Maria Hospital IT Department’s EA. Implementation of Vicente’s Work. Vicente’s work [1] proved to be an interesting topic that has a great resemblance and connection with our proposal. Therefore, we’ve followed a first line of deploying all his work to Link’s EAMS tool. Having an EA representation of ITIL will be really useful when combining all the elements necessary for our demonstration. Furthermore, the ITIL elements Vicente has modeled will be directly connected to our TIPA’s ArchiMate representation of the Incident Management Assessment (chosen TIPA process assessment for validation of our proposal) which will simplify our demonstration process. Fig. 12 in the Appendix B Section shows Vicente’s work realized in the EAMS tool for the Incident Management Process. IT Department’s Enterprise Architecture. After extending Vicente’s ArchiMate representation of ITIL into EAMS we entered in contact with our field study target, the IT Department at Santa Maria Hospital. We had a meeting with the director, Eng. João Louro and explained him the focus of our thesis and how the department could benefit from using this approach in implementing ITIL. We started by installing our EAMS Database in a virtual server inside the department that was then populated with all the collected data regarding their EA. Concerning the collection of all their EA elements, we started by surveying their infrastructural and application elements. Those were collected and populated inside the EAMS Database. Fig. 13 in the Appendix B Section illustrates some of the Department’s applications in the EAMS. Afterwards, we started by surveying and modeling their business processes and mapping them with ITIL. However, for our thesis main focus only the activities 19 related with the Incident Management process of ITIL were prioritized. Table 1 illustrates the surveyed activities related to the Help Desk area of the department and how far they are from being compliant with the activities that compose the ITIL Incident Management Process. Activity Incident Identification Incident Logging Incident Categorization Incident Prioritization Initial Diagnosis Incident Escalation Investigation and Diagnosis Resolution and Recovery Incident Closure Implementation Status Software: OTRS Software: OTRS Software: OTRS Software: OTRS Software: OTRS Table 1. Compliance mapping between the IT Department’s Help Desk Activities and ITIL Incident Management Process Activities By analyzing Table 1 we came to the conclusion that the IT Department’s Help Desk division is not far from having an automated implementation of the ITIL Incident Management Process. Throughout the Incident process pipeline they use an open source software application called OTRS that features most of the ITIL Incident Management Activities. However, as we can see from the red implementation status cells, the Department is not yet compliant with the Incident Categorization and Incident Prioritization (both paid features of the OTRS system) and also with the Initial Diagnosis and Investigation and Diagnosis activities. 6.2 TIPA in EAMS In this section we will describe the work that is yet to be done concerning our proposal demonstration and which approaches are we following towards its conclusion. After having our model implemented and validated, the next step will be the realization of that model inside the EAMS tool. For sake of simplicity in the demonstration of our proposal we will just consider the ITIL’s Incident Management process. The next steps of our demonstration are identified below:  Import the Help Desk’s activities to EAMS 20     Import the TIPA Incident Management Assessment instantiation to the EAMS Relate the EA elements of the IT department concerning the Incident Management Process with the ITIL and TIPA’s instantiation of that process Create an application as a module of EAMS with the function of providing a dashboard of costs, resources, time amongst other possible features related to the current level of maturity achieved by the IT Department regarding Incident Management. Show our demonstration to ITIL experts and to the IT Department’s staff and director for validation purposes. With these features inside our EA tool, we are able to show how the EA of the IT Department should adapt in order to become fully compliant and mature regarding Incident Management by minimizing its efforts, time, costs and resources. 7 Evaluation This section refers to the “Evaluation” step of the DSRM process, where we will do an evaluation of our proposal. Besides the Demonstration as the primary source of evaluation of our work, we will consider another three steps in our evaluation. For evaluating our TIPA metamodel we will use the Wand and Weber [28] ontological analysis method to evaluate our concept mappings from TIPA to ArchiMate. Afterwards, we will use the Moody and Shanks Framework [10] to evaluate the quality of our model. Later on, we will interview stakeholders from ITIL experts to the director and employees from the IT Department at Santa Maria Hospital in order to validate the correctness and the utility of our proposal to the scientific and organizational community. Those interviews will also serve as input for the Moody and Shanks evaluation. Finally, we will submit a paper on the subject to an international conference or journals for peer review. The submission of papers is described in the Communication section. 7.1 Demonstration Evaluation The main evaluation source of our research work will be its practical demonstration as described in section 6. The way we plan to demonstrate our proposal will already take into consideration its utility, value and correctness. Moreover, our demonstration is also planned to be an important part of our future interviews with experts in ITIL, Maturity Models, EA and the Hospital Santa Maria IT Department staff and board. Therefore, by showing our proposal demonstration to these experts and stakeholders, we are also guaranteeing the validation of the correctness and value of our proposal to both the scientific community and the organizational community. 21 7.2 Interviews Interviews allow asking questions that are open-ended and explore emotions, experiences or feelings that cannot easily be observed or described via pre-defined questionnaire responses [29]. So, we will use this method for distinct stakeholders of the several research areas of our work in order to validate the value and correctness of our proposal. Furthermore, one of the purposes of these interviews besides the scientific and organizational recognition is using the Moody and Shanks criteria (described in section 7.4) as foundations of those interviews in order to classify our work according to those respective criteria. Our interviews will mainly focus ITIL and TIPA experts and also the staff and board from the Hospital Santa Maria IT Department. We will then consider if time allows, interviewing other organizations focused on IT and services in order to collect more data and feedback to help consolidate the overall evaluation of our proposal. 7.3 Wand and Weber Method For evaluation of the concept mapping from TIPA concepts to ArchiMate’s ones we will perform an analysis based on the Wand and Weber ontological evaluation of grammars method where we will try and identify four ontological deficiencies in the comparisons of the two sets of concepts from the two universes: TIPA and ArchiMate.     Incompleteness: can each element from the list set to be mapped on an element from the second? – the mapping is incomplete if it is not total. Redundancy: are the first set elements mapped to more than a second set element? – the mapping is redundant if it is ambiguous. Excess: is every first set element mapped on a second one? – the mapping is excessive if there are first set elements without a relationship. Overload: is every first set element mapped to exactly one second set element? – the mapping is overloaded if any second set element has more than one mapping to a first set one. 7.4 Moody and Shanks Framework For evaluation of our TIPA metamodel we will use the The Moody and Shanks Framework [10] for model quality management which proposes the following quality factors:   Completeness refers to whether the model contains all user requirements; Integrity definition of business rules or constraints from the user requirements to guarantee model integrity; 22       Flexibility is defined as the ease with which the model can reflect changes in requirements without changing the model itself; Understandability the ease with which the concepts and structures in the model can be understood; Correctness is defined as whether the model is valid (i.e. conforms to the rules of the modeling technique). This includes diagramming conventions, naming rules, definition rules, and rules of composition and normalization; Simplicity means that the mo