Different efforts have been developed focusing on the alignment between organizations' concepts. From these initiatives, two have had outstanding relevance: The Open Group Architecture Framework (TOGAF) and IT Infrastructure Library (ITIL). However, these two approaches are often used complementarily and simultaneously. Beyond the difficulties associated with governance, parallel projects with similar initiatives imply the duplication of resources and thus costs. The integration of both approaches in a same referential avoids the need to adopt different frameworks covering overlapping topics. This paper presents a case of integration between two of the most known and used frameworks, respectively TOGAF and ITIL. We demonstrated and evaluated our case applied in a field study inside a public organization.
The growing dependence on IT leads to the improvement of initiatives focusing the
business/IT alignment and cost reduction [
Once ITSM and EA 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.
Although some have tried to integrate these two approaches by identifying several
benefits from the relationship and integration of ITSM and EA, the results are far
from satisfactory [
In this paper, we1 present a case of integration between EA and ITSM through the
integration of their two best known and used frameworks, respectively The Open
Group Architecture Framework - TOGAF [
EA is recognized as the core element for the representation, in layers, concepts and
artifacts, of an organization’s systems and properties and how they are related. EA
allow us to observe the organization from different views and perspectives in a
coherent whole of principles, methods and models, used as an integrated approach in
the design of the whole enterprise’s organizational structure [
Different needs, scopes and authors have proposed different EA frameworks with
common principles. From these frameworks, TOGAF [
ITIL is a the de facto standard to IT Service Management in a collection of process oriented best practices, documented over the years, related to the effective and efficient management of IT.
One of ITIL main concepts is the service orientation, involving layers and
components common to the TOGAF framework. Moreover, ITIL encapsulates a
composition of architectures, namely business, processes, information, application,
and infrastructure. However, ITIL neither provides a complete coverage for all phases
within TOGAF nor does ITIL specifies implementation details [
The modeling of ITIL is made from a concept description in natural language,
while ITIL processes are usually depicted as well defined sequences of activities by
flow charts [
Summarizing, the integration between TOGAF and ITIL makes sense since both frameworks cover and relate common subjects. However, this subject remains a nonsolved problem. Despite the interest and research in both areas, ITIL and TOGAF have rarely been studied together even less practical cases. 3
We demonstrated the validation of our approach by integrating TOGAF and ITIL in the “Centro de Dados da Defesa” CDD, the IT Department of the Portuguese Defence Ministry (MDN).
CDD provides IT services and respective support to Portuguese Defense forces (MDN, Navy, Army, Air Force, and EMGFA), more than 800 users, plus 3,000 users from “Sistema Integrado de Gestão” (SIG) based on SAP.
CDD is a Service Directorate of Secretaria-Geral from MDN, who has a top director (Secretário-Geral) and an executive officer (Secretário-Geral Adjunto). Beyond CDD, there are other Services Directorates in the Secretaria-Geral such as law and justice (DSAJ), provisioning (UMC), finance (DSAF), planning (DSPC), human resources (DSGRH), public relations (DSCRP), and SIG/SAP development (DSSI). CDD has approximately 40 people divided in four technical areas: support (ATAU), communications and security (ATACS), operation and systems administration (ATAOS), and systems and applications (ATASA).
These people have good technical skills, know-how, and all have an ITIL certification. All areas had defined competences and the technical support to the other technical areas. The support technical area (ATAU) also ensures the ITIL’s Service Desk function.
The CDD was increasing the number of adopted ITIL processes by developing change management, configuration management, and event management. CDD already had in production incident management, request fulfillment, problem management, and service desk function.
Due to the widespread knowledge of ITIL best practices in the CDD, any initiative should be based on this common knowledge of practice based on ITIL. 3.2
A previous project was conducted to raise the enterprise architecture of CDD. In the beginning, there was some difficulty to start and involving the CDD’s people, due to their work overload. Only with some organizational principles related to change management was it possible to achieve some results from the project team, namely: presenting the EA advantages; involving people in decisions; sharing and relating the elements managed by each technical area; following Business Process Modeling Notation (BPMN) to identify processes; and increase transversally in the relationship between technical areas.
However, BPMN was revealed as insufficient to model the processes in a coherent way along different technical areas, and even less along layers of the enterprise architecture. Notwithstanding, we developed an architecture metamodel based on TOGAF supported by IBM Rational System Architect2 and the respective database, as the EA repository.
Each technical area contributed to identify the elements they managed and efforts were done to relate those concepts. At that time, each technical service area identified its services. However, these services were identified with different levels of granularity, and only a small part of the services were identified.
Most of the models were well depicted as most of the views had already been designed with MS Visio. However, some additional effort must be done due the verified duplication of work, which was a big obstacle to motivate people.
Once all the information was loaded into the EA repository, it was possible to identify and show some relationships between concepts. Despite the initial good results, the architecture quickly became outdated due to the ineffective follow-up of governance policy needed to keep the project alive: technical areas managed their assets in different information repositories; and the technical support area kept information of Configuration Items (CI) separated from the EA repository.
The project was abandoned. Some of the identified causes to the less positive results in the project were: • • • • • • • • •
EA repository without constant updates; The use of different repositories to manage CI’s and assets, without communication or dynamic actualization between them; Different languages for modelling different layers; Modelling language (BPMN) insufficient to model coherently along layers; Different granularity modelling levels; Incoherence in the adopted metamodel; Absence of processes linking technical areas; and
Unawareness of the advantages in using a single information repository. Furthermore, the ITIL processes were designed without any integration with the EA project. For example, at that time the CMDB only managed the IT assets while others CI were managed in different repositories. 3.3
After identifying the strengths of CDD and controlling the failure causes of the prior project, we started a second EA project based on the lessons learnt.
Our approach was based in the TOGAF framework, using the ITIL processes to keep the EA updated and able to be used in a day-by-day basis.
From an overview of some languages for modeling EA, ArchiMate has proved to
be the language that covers all domains in the area of organizations [
A single EA repository was vital to the integration purposes. Therefore, we identified the information sources from all technical areas, namely the ones needed to design the enterprise architecture.
Finally, we realized that the only way to link the different technical areas was
using the same concepts and processes [
Therefore, based on the lessons learned, the definitive project to build the enterprise architecture in CDD followed a sequential method with the following initiatives: 1. The conclusions from the previous project were presented to the key decision makers, to the people involved in the project, and to the key users. 2. Were explained to the stakeholders the objectives of this second project, namely the principles, methods, and models to be used. 3. Was created a dedicated team with defined competences and responsibilities. 4. Was created a board with people from all technical areas. This board would have particular importance in the change management processes. 5. ArchiMate language was used to create a baseline model in each layer’s architectures, modelling different organization viewpoints, and filling the needs from the different stakeholders. 6. From the previous project we concluded that a single repository was vital to the integration purposes. 7. Were identified different information sources used to manage information under each stakeholder responsibility, integrated in the information’s repository. This integration allowed identifying and visualizing the relationships among concepts. 8. Developed the service catalogue with two views: a business service catalogue and an IT service catalogue. To each business service, was modelled how IT services realized business services, depicting the concepts and relationships along layers. 9. Identified EAMS3 as the tool to support EA integration and visualization in accordance to defined pre-requisites. 10. Defined a change management process to be followed, focused on keeping EA updated. Beyond the process definition, the change management process implied the definition of roles to support different decision points.
The results from the previous project were not as good as CDD expected. After an initial enthusiasm, the people involved were quite disappointed. Therefore, it was needed to recognize the weakest points. Also, there was a need for hierarchical and political support to this new initiative. A new project implying operational changes, the adoption of a new approach, and a referential model are all disruptive changes in the organization that may cause some change resistance.
However, it is a duty of organization’s directors, especially those related with IT,
to provide the means to the people in an organization to internalize its referential
model [
The conclusions of the prior project were presented, including what was needed from lessons learnt.
A small team was then created, including two dedicated people, from the beginning of the project. Also roles and competences were defined, namely the ones related to the change management process. 3 Enterprise Architecture Management System (www.linkconsulting.com/eams)
The project started identifying the core concepts from ITIL and TOGAF approaches, focusing on how their concepts are related. After that, we integrated the concepts from both approaches finding the common ones and solving concepts duplication.
As the ArchiMate is used to model TOGAF [
However, ITIL should have the necessary concepts to be fully represented in
ArchiMate. Since ITIL does not have an ontological relationship between concepts,
we used an ITIL metamodel [
At this point, we already had the ITIL metamodel [
Our solution allows the mapping and visualization of the organization’s actual state, top-down and bottom-up. This is equivalent to the EA’s “as-is” model and allows, from ITIL principles, ensuring service delivery through all architectures.
Thus, once TOGAF is the basis for EA development, the ITIL processes were integrated into TOGAF using ArchiMate as the common language.
Regarding the information integration, we identified the information sources from each technical area. CDD had several sources of information serving the information needs of the four technical areas.
We identified several and distinct information sources, from highly structured information such as Active Directory (despite some inconsistent information), less structured models (BPMN processes), or even documents such as Microsoft Office (Word, Excel, PowerPoint and Visio), among others.
Information integration must be made from structured sources, therefore,
integrations with unstructured sources require prior structuring work [
Hence, we identified the information sources from each technical area in the defined metamodel. Were realized, with each of the four technical areas, a few meetings to identify information sources. We identified, clarified, and selected 12 main sources of disparate information that was integrated.
Each technical area managed information relating to their respective functions and technical competencies. This information was not integrated or even shared, as each technical area had its own database with related information.
From the identified information, we developed the architectural layers: infrastructure architecture involving the servers and networking views; data architecture with databases and instances; and applications architecture. The following figures illustrate some parts of the infrastructure architecture models. More than modeling each of the architectures, we were able to identify the different sources of information, and we developed connectors to keep information updated.
We used defined viewpoints to model the process that update the information related with the Configuration Management System (CMS). As we can see in the Figure 2 below, every technical area has a configuration manager responsible for maintaining the information needed to manage their respective technical area and a direct relationship with the change management process.
We considered each business service as one CDD output. From each business service we identified the activities’ sequence (processes) that delivers these outputs, which allows identifying used applications, information accessed or created, and the support technologic infrastructure.
Defining the business services was challenging because, although ITIL is a set of
best practices based on the service lifecycle, in ITIL it is not clear how to create a
service catalogue from scratch [
We created our service catalogue from our incident database using a reverse
engineering process [
Nowadays, the service catalogue is an official document from which the CDD’s activities are developed. Each business service has an individual description and characterization, with manager, Service Level Agreements (SLA) and IT services that support that service.
From the ITIL Service Catalogue, we had an overview of all the IT services provided and how they are supported. Figure 3 presents an example of a service’s model. Each service is decomposed along layers, from the business to the technology layer.
In an organization we have different types of change occurring in different times and with different impact. Therefore, beyond a unique process reflecting change in a common repository, we should evaluate and deal differently with different types of change.
We adopted a change management process integrating TOGAF and ITIL practices, clarifying the results and impacts of changes. This was based on a repository that shows how artifacts are related, predicting the impacts, and realizing what must be undone if problems occur with changes.
To the best of our knowledge, the problem of keeping up-to-date EA in an automatic manner is an issue to be satisfied. Without an up-to-date EA we cannot present a view as a valid viewpoint depiction. Four main issues must be addressed: first, we should identify what has to be changed, evaluating the involved implications; secondly, the update of information about what has changed; third, ensure that the changes are reflected along information flow, from the ones making the changes to the ones updating the repercussions; finally, the rules to update the viewpoints depiction.
The defined change management process based on the relationship between concepts along the defined metamodel allows to:
Ensure the recording, evaluation and processing of all changes; Identify and evaluate the impact and risk associated to each change; Define the change’s type and ensure the understand of the difference; Clarify competences to handle to each type of change; Consider low impact changes that could be implicitly pre-approved with a short evaluation.
Keep EA updated is a challenge. However, only if permanently updated, an EA can be used as a tool to manage organization on a daily basis. Since TOGAF and ITIL deal with change management differently, we adopted a change management process entailing the best of the two approaches.
As such, we considered that any change with results reflecting in the EA should be previously evaluated, registered and saved in the respective information repository.
A change assessment should be performed and, depending on each type of change, a categorization should be performed in terms of impact and risk. The decision must depend on the level of evaluation by the respective role.
We address the change issue depending on each type of change. Figure 4 illustrates the adopted change management process. 4
After having been identified the CDD information sources, we imported the data into
the common repository, integrating all identified information sources scattered
throughout the CDD’s four technical areas by introducing the information directly
into the information repository.
We used EasyVista’s Configuration Management System (CMS) to store the data and
the EAMS to load our metamodel, access the overall information, generate
architectural viewpoints and views, predict change, and manage projects. The EAMS
tool’s principles are defined in [
We loaded our metamodel to EAMS, defining the core concepts and their respective relationships, from infrastructure technology to the business services. After having identified the information sources, structured the information, and defined the relationships, we imported the files (most in CSV and XML formats) to the CMS, with information from the different sources of the CDD’s technical areas. The services that were modeled in ArchiMate were loaded into the EAMS.
We also imported textual information from the other information sources such as Excel sheets, Word documents, and Visio diagrams, among others. All this disperse information was loaded into the CMS as the centralized repository.
The CMS was linked to the EAMS. The CMS artifacts were linked to the Archimate artifacts in the EAMS. Whenever a change is made in the CMS, it is reflected and updated in EAMS. On the other hand, prior to make a change, their impact was evaluated in the EAMS
Some of the identified information was kept in different databases such as the information related with MDN’s people that were kept in the Active Directory (including name, contact, department, and roles) or the information related to SIG/SAP users. However, all the information relationship was established and kept in the EA repository. On the other hand, all information sources were kept updated in accordance to a defined change management process.
Thereafter, we created different profiles to CMS access, allowing each technical area to access and manage only the information that concerned that area.
The Figure 5 represents a generic overview of the adopted technical solution to proposal’s implementation. Regarding the information integration, we imported the information into the common repository, integrating all identified information sources scattered throughout the technical areas to avoid introducing the information directly into the information repository.
F 5 – Overview of the Implemented Solution All information is uploaded to the EAMS repository through connectors with the different information sources. Everyone that has access to the CDD’s intranet can access the EAMS’s viewpoints.
Figure 6 presents the conceptual adopted solution. The left side of Figure 6 shows some of the documents loaded into the CMS.
The center of Figure 6 shows the information provided by the CMS to EAMS visualization purposes.
Considering the subject of the CMS, one of our tasks was to prepare a repository that supports the evolutionary vision of the architecture. The CMS keeps the information describing the organization and enabling the automatic generation of architectural views.
Previously, we identified, defined, and implemented the graphical models that represent the stakeholders’ interests in the enterprise architecture. Those viewpoints allow views answering the stakeholders’ needs. A key aspect is that these models must be generated automatically. We used well-established viewpoints supported by EAMS.
The right side of Figure 6 presents examples of the architectural views generated by the EAMS tool. In addition, to the more traditional static visualizations, the solution allows interaction with the representations.
Stakeholders may interact with the created view by selecting and inquiring information about artifacts and navigating between views.
Whenever the organization already has the processes to maintain and update a particular source of information, one should provide the automatic import mechanism to integrate it. All types of changes should be carried through the defined change management process. It is not easy to share an organizational common understanding of concepts and architectures. The mapping and analysis between ITIL and TOGAF was challenging since concepts are specified in natural language and graphical representation, but mapping in different models with formal semantics is complex. That is, the human comprehensible description hardly has the same meaning to different people, leading to different representation and interpretation of the concepts.
We addressed this problem by means of integration between concepts of ITIL and ArchiMate, as the adopted language to model TOGAF.
At the project’s beginning, many people were quite skeptic. People with EA background were more receptive to ArchiMate as a modeling language, than people from ITIL. First, because ITIL people already knew how to model processes using BPMN. Second, they knew about ITIL and had never seen an entire EA modeled project using ArchiMate. However, the first models were presented with good results due to their quality since they have a clear relation between the model and the used language. The models were correct and answered their needs. After all, people recognized utility and even completeness, as the models answered their management needs, using the same concepts among people from different teams. ArchiMate was the language that allowed modeling along different EA layers but also through all technical areas. Once learned, the modeling language was valid to model and to communicate among technical areas.
We analyzed the relationship among the concepts from ITIL and TOGAF identifying the relationship. The integration between TOGAF and ITIL using a single modeling language and, mainly, a single repository to keep and manage the information related to their needs, resulted in a well-received solution.
Service orientation allowed the identification of activities from disparate technical areas, identifying transversal and common processes.
The integration encompassing the relation between TOGAF and ITIL, with the identification of information sources and the relationship among concepts, required a shared and single repository. Otherwise, IT is a collection of artifacts to meet technical requirements. Since the concepts and their mapping were defined, the common repository was used to store the organizational relationships among concepts.
Some tasks were time consuming, namely the time spent adjusting unstructured information and manually guarantying the information quality. However, this activity was vital as people cannot lose confidence in their information, and we needed to show short-term results.
Instead of disparate information sources, managed separately, the relationship between information items was mapped. Each technical area contributed with information that relates with information from other areas, entailing an important transformation in the organization, with homogenized languages and tools. Nowadays, the information serves the CDD interest as a whole instead of relating to a unique technical area. The achieved results were quite interesting, allowing us to provide consolidated and updated information to the various technical areas through views of the architecture: • •
Consolidated as we have results from the information provided from different areas and from disparate sources; and Updated as we have results from information sources maintained and updated by the stakeholders from the different technical areas through the proposed change management process.
The adoption of a unique approach and common language enabled the raise of a definitive EA in the CDD, promoted the creation of synergies and also the use of the EA in an operational way.
ITIL principles and processes guarantee the update and consistency of information with standard processes, such as configuration management and change management. The adopted change management process allows to handle with any type of change homogeneously and reflecting on keeping the EA updated. These processes ensure the reliability of data recorded and accessed in the common repository, allowing us to see the changes' effects.
Synthetizing, we may say that we identified several benefits from the integration between TOGAF and ITIL approaches, namely: •
Reduced the duplication of efforts by avoiding parallel development initiatives; • • • •
Integration of the principles related to IT service lifecycle into EA approach; Created synergies from ITIL and TOGAF thereby creating a greater impact on results; Sharing of concepts, language, and tools; Increased the communication and collaboration among technical areas; Share and exchanging information; and
Development and maintenance of a consistent view of the same reality.