Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Information technology (IT) plays a fundamental role in organizations. The more important the role of IT, the more complex the IT infrastructure and the harder it is to manage. The growing demand on IT leads to the improvement of key concepts related to IT governance, in particular the ones connected to IT alignment with strategic objectives and cost reduction initiatives.

For many years now, different efforts have been made related to IT governance; however, results are far from what was expected, and the gap between IT and the results expected by the organizations’ objectives leads to an increasing interest in alignment efforts and related frameworks. From these initiatives, two main approaches have had major relevance: Enterprise Architecture (EA) and IT service management (ITSM). EA summarizes the relevant components in an organization, how they are related, and how they fit and work together in different architectures and with different views [1, 2]. ITSM is a reference model with an integrated approach to effectively and efficiently deliver IT services, providing a better IT alignment with organizations’ needs [3–5], with cost and risk reduction [6]. From ITSM area we have frameworks related to IT governance, like ITIL, COBIT, and CMMI for services, just to name a few. From these, ITIL has become ITSM standard, currently the most widely accepted framework for managing IT services in the world [6–9]. As a result, this study will pay closer attention to EA and ITIL.

Today, there is no fully complete framework that can be used as a comprehensive off-the-shelf IT governance framework to ensure the alignment between service management and the organization’s concepts and artifacts. In fact, different frameworks are often used as complementary and, most of the times, simultaneously too. Beyond the difficulties associated with the governance of both initiatives, parallel EA and ITIL projects imply a duplication of investments and costs. Indeed, even with shared infrastructures, we cannot avoid a duplication of data repositories, procedures, and human resources or maintain different efforts (ITIL and EA) aligned. Although some have tried to merge these two approaches by identifying several benefits from the relationship and integration of ITIL and EA, the results are far from satisfactory [7, 10–12].

This paper provides a research in two widely used frameworks to manage and align IT with business, allowing guidelines to adopt a single initiative that involves the merger and alignment between EA and ITIL approaches. A merged approach would avoid the duplication of efforts, cost, and time through a unique path. Thus, this paper provides a proposal to adopt a common guidance. Through ITIL principles, we suggest using the services delivered as the key point of integration between EA and ITSM.

2 Research Methodology

The methodology applied in the course of this paper is Design Science Research Methodology (DSRM). We selected this methodology because we wanted to develop and validate a proposal to solve our problem but had no initial validated theory [13, 14]. DSRM is a typical problem-solving paradigm, 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 causes and design solutions [13, 14].

We follow DSRM according to a process model with sequence activities [15, 16]; each sequence corresponds to the following sections: Section 3 covers aims and objectives like awareness and recognition of a problem from a literature review, hence giving us the theoretical background and the topics to be addressed. Section 4 clarifies the main problem and our research questions, offering a tentative idea of how the issues might be addressed and defining the objectives for a solution. Section 5 presents the design of a proposal as an attempt to face the previously described problem. Finally, we present a “Demonstration” that solves an instantiation of the problem and is followed by the “Evaluation,” which compares the results with the research questions. We end by proposing themes for further work.

3 Related Work

3.1 Enterprise Architecture

Enterprise Architecture (EA) is a coherent set of principles and the basis of knowledge and representation of the organization itself. It has become the methodology that best enables the planning and development of systems and IT aligned with business [1, 2, 17]. EA involves the design of different architectures and specifies the orchestration among them, being used to manage and align assets, people, operations, and projects to support business goals and strategies [18, 19].

Different needs, scopes, and authors have suggested distinct representations and architectural frameworks (e.g., ArchiMate, TOGAF, and DoDAF just to name a few), decompositions or domains, having in common principles like a holistic representation of organizations, relationships between artifacts and architectures, and independence and connection among layered architectures.

The decomposed representation of organizational layers (as seen in EA) usually shares the following architectures [1, 11, 17, 18, 20, 21]: business, process, application, information, and technology. The architecture alignment takes on particular relevance, and EA integrates each of these into a cohesive framework so as to obtain a coherent “blueprint” of the organization [22].

Besides EA principles, the implementation of a manageable and configurable EA requires the use of appropriate tools, including a vital data repository that backs up the development, storage, presentation, and enhancement of the organization’s architecture representations [23]. The EA repository has many similarities with the one of a Configuration Management System (CMS/CMDB) from ITIL.

Even though EA principles make a clear reference to the correlation between architectures, they do not specify how to control and manage the different artifacts within them in a day-to-day basis.

3.2 ITIL

The acronym ITIL refers to Information Technology Infrastructure Library, a collection of five books with the best practices related to the effective and efficient management of IT: Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement.

The current version of ITIL covers the major weaknesses identified in the previous versions, specifically being too focused on technology. Now, the focus is on the overall service life cycle management, allowing a wider coverage of IT governance to address the “business alignment aspect” [5, 11, 24].

ITIL framework is underpinned by the Configuration Management System (CMS), which is defined as a set of tools and databases (CMDBs) for collecting, storing, managing, and presenting data about all configuration items (CI) and the relationships among them that influence the business [24]. Everything can be recorded as a CI such as hardware, applications, and interfaces but also information about incidents, known errors, changes, people, manuals, and service-level agreements (SLAs). Conceptually, a CMS supports ITIL’s management processes described for service management, but it is also a shared center of decisions and the global “as-is” of organizations’ systems. A CMS has a lot in common with EA principles. However, ITIL framework makes no reference of how we can develop these architecture definitions. We can use ITIL in EA to design the service management of an organization because ITIL is a reference model for IT governance. However, ITIL neither provides a complete coverage for all layers within EA nor does it specify implementation details [25].

3.3 SOA and Business–IT Alignment

Service-oriented architecture (SOA) is a paradigm oriented to provide business agility in order to respond quickly to changes in business by re-architecting business processes, creating new ones, or architecting existent IT as services exposed in business services [26]. The loose coupling characteristic of SOA’s agility works as a basis for achieving architectural alignment [27]. In fact, service composition and orchestration are an advantage of SOA paradigm [27]. Each service, in SOA, has different granularity and may support business processes, singly or with services choreography. Moreover, the meaning of service is different in each referential.

There are many different definitions of SOA [28]; some are more related with Web services, applications’ functions, and software development [26, 29], while others consider SOA an architectural approach that emphasizes service concept and service consumers as a basis to structure the entire organization [30]. Therefore, we adopted the definition from ITIL [24] and Noran [30], in which a “service” means the creation and delivery of value to users by easily fulfilling their needs without having specific costs and risks, which are made up from a combination of people, processes, and technology. A service, in a business sense, is then defined as a provider–client interaction that creates and captures value [27]. Here, users know what services they want but do not know how they are delivered [27].

3.4 Relationship Between ITIL and EA

ITIL and EA have rarely been studied together, and no relevant results about the relationship (interactions) between these two approaches have been produced. Much of the previous work was focused on previous versions of ITIL, only covering service delivery and support [11]. Therefore, this subject remains without significant development, which increases our work’s interest and relevance.

ITIL books promote the connection between ITIL and EA in Service Design [24] and recognize that architecture components should cover all areas of technology. However, the architectural conception is not considered in deployment and the distinction between EA and IT architecture is not clear; service architecture is in fact IT that we will define as IT services [24].

Braun and Winter [10] proposed an EA expansion to integrate ITIL (V2 at the moment) and SOA. In their proposal, EA is considered a key concept, but ITIL is only regarded as IT operations. EA provides an overview of the IT architecture, while ITIL was assigned as an essential part of the management processes to service delivery. Aligned with the IT services, SOA concept is also integrated into EA at the application architecture level. ITIL and SOA were integrated into EA as a framework to deliver IT services, focusing this research of integration only on delivered IT services.

Almost aligned with the previous study, Thorn [12] addresses the relation between ITIL and TOGAF but with a different focus. EA is regarded as a fundamental concept for organizational engineering, focusing on EA development, in which ITIL is included as a framework to an operation model for IT delivered services. In his research, Thorn argues that both frameworks can be used together by mapping the two approaches. TOGAF covers the development of EA and is involved in the product’s conception life cycle, whereas ITIL ensures the delivery and management of IT services to users and consumers [12]. Despite the recognized need of different teams and tools, the two frameworks complement each other, since TOGAF needs an EA repository, while ITIL requires a CMDB.

A more recent research promoted by Nabiollahi [11] provides a service-based framework for EA to meet the ITSM requirements of ITIL V3, suggesting that EA should be extended to involve service architecture layer from ITIL Service Design [24]. The development of an architecture model for IT services is proposed, making it a service layer for EA. However, it does not clarify how to do it or the relationships among architectures.

Another research concerned with a more generic and technology-independent view on IT services was developed by Correia [7]. In this research, ITIL supports services from an operational perspective through a CMDB, while EA repository is used to store the architectures, sharing a common data model and the same ontology. Correia’s research then suggests a common ontology, a meta-model, and the sharing of IT services, specifically the formal representation of framework concepts and their relationships, both repositories existing at the same time.

4 Research Questions

EA principles aim to represent organizations as a system, relating multiple architectures to their artifacts and components. The widespread scope of ITIL involves all organizational architectures, but it does not describe how to deploy it. Currently ITIL and EA teams work in different parts of the organization with little opportunity to share expertise. Initiatives to address the alignment between IT and organizational issues have lead to an overlap of the work developed. The efforts spent in managing organizational data in separate repositories, from different initiatives, EA and ITIL, might become unmanageable. Therefore, both approaches should be merged.

Our research question “How to integrate ITIL and EA initiatives in a single body, avoiding efforts and resources duplication, but keeping all the benefits” will be answered by the following secondary research questions:

  • Which is the key point between the two approaches and how can it be defined?

  • How to merge both approaches, considering the effort and magnitude needed to build and maintain coherent information and, especially, their relationship?

  • Since the integration of all processes and artifacts makes it necessary to have a tremendous amount of additional development and maintenance effort, how to keep the merged information up-to-date?

The answer to our questions derives more from the process side of the solution than any other. The problem we are trying to address is organizational engineering and the solution encompasses a conceptual model, independent of tools or adopted frameworks.

5 Proposal

The alignment approach among SOA, EA layers, and ITIL was already depicted by Chen [27] and Braun [10]. However, both researches (based on ITIL v2) suggest a relationship among approaches and not their integration.

Therefore, we propose to merge both ITIL and EA initiatives in a single body restricting resources and efforts. The suggested solution allows the mapping and visualization of the organization’s actual state, top-down and bottom-up. In EA parlance, this is equivalent to the “as-is” model and allows, from ITIL principles, service delivery through all architectures. The solution we offer encompasses all the EA principles with referred architectures (architecture layer in Table 1) and the relationship among them, following ITIL service management processes.

Table 1 Aggregation of concepts
Full size table

We started by identifying a set of concepts, keeping the ones common to EA and ITIL, with strong relation to main concepts. From all of them, we also identified the interfaces, keeping the loose coupling characteristic from SOA paradigm. To do this, from the relationships among SOA elements in EA frameworks [31] and among the core artifacts of EA with cross-layer views in different frameworks [21], we introduced the main ITIL artifacts and management processes. The results are shown in Table 1.

To clarify the relationship among concepts, we used a model as a graphical representation, allowing people to recognize the relationship among concepts in different architectures or views. Models are effective artifacts that support understanding and communication [5, 32]. Concept maps are, by definition, a graphical representation to capture, represent, structure, and share tacit knowledge, specifically concepts and the relationships between them [32, 33]. Beyond a knowledge representation, a concept map is as an evaluation tool due to the development of high levels of cognitive performance [34].

EA represents an organization from a strategic output to technological infrastructure, through layered architectures. Therefore, one of the very first definitions should be about the Product/Service delivered, the organization’s output.

The Product/Service provided ought to be aligned with strategic orientations and integrated with defined goals. In turn, strategy is influenced by the services we want to offer to users, whose opinion is developed by what we deliver [6]. An effective service orientation is about providing what users need. Nevertheless, IT only has value to the business if it delivers the expected services. Therefore, we linked all activities with business objectives from Product/Service. Due to strategy definition, the Product/Services can be described as the focal points of business activities, shaped according to strategic requirements since users are only able to understand and pay for what we deliver them (the users’ view of the service). Therefore, services have to be defined and measured from the users’ perspective. From a business point of view, their identification is even a prerequisite to clarify the services critical goal. A service definition should promote a direct strategic effect, which can be measured [35]. From a technical point of view, services are translated into basic services, with elementary functionality [35], in IT services. An IT service identifies what is required to support a service, so it is not essential to know users’ needs in detail, because they are already translated into Product/Services. From a different perspective, we clarify what IT services are needed to provide the defined services. However, it is crucial to determine how these directly affect the performance of services.

In order to be clear, we will determine which activities should be developed to support IT services, namely, the activity sequence—our processes. By activity identification, we will determine the provider involved, applications used, information CRUD, and supporting technological infrastructure. The next step is to integrate all identified concepts, defining the correspondent architectures. We used a layered approach identifying and linking architectures and elements. Figure 1 illustrates the conceptual map of integration between concepts from which we define and establish the relation between elements and architectures.

Fig. 1
figure 1

Conceptual map of integration between concepts

Full size image

We continued the work, establishing the relationships as we went along, and stored the data into our footprints, providing different views as visualization of the relationships.

Each concept provides services to the related concepts with SOA elements, namely, service description, service policy, and service interface. We did not represent all elements in Fig. 1 to improve understanding.

The service-level agreement (SLA) is established by the strategy and defines the services, which are translated into the service catalogue.

The defined correlation among elements and architectures is established through services using SOA principles, allowing the implementation of ITIL processes, and mapping the integration between the two frameworks (ITIL and EA). The ITIL service life cycle concept, described in ITIL books, is developed as follows: Service Strategy addresses where, why, and what services should be done; Service Design defines how to meet strategic definitions, translating Product/Services into services; Service Transition is connected to the services deployment into operations and related processes; operational day-to-day activities are treated by the Service Operation; and Continual Service Improvement permanently addresses the gap analysis between current and desired states.

Therefore, having EA as the basis for organization’s representation, through different and independent architectures, we can map the service life cycle with architecture relationships. The entry point of both approaches is the Product/Service definition, the pivotal point of integration between the ITIL and the EA approaches. From the conceptual map, clarified by the concepts, relationship, and integration between both approaches, we are able to define our meta-model. In Fig. 2 we present the simplified meta-model of our proposal.

Fig. 2
figure 2

Simplified meta-model

Full size image

6 Demonstration

To demonstrate and validate our proposal, we decided to solve an instance of the problem [16] and applied our proposal to an IT department of a Portuguese public organization where there were two different functional divisions with responsibilities related to EA and ITIL. Each team has a clear idea of its functions, developed tools and procedures to help them separately. Moreover, knowledge is rarely shared and changes are barely discussed involving the two teams. As a result, there were constraints due to some subjects’ overlap, which led to some competition between teams. This causes duplication of resources translated into wasted of time and money.

Despite well-known problems and some initiatives related with the sharing of knowledge and work, the issues remain and it is still difficult to represent and agree to a shared knowledge. To better the service level, the organization must improve the alignment and coordination between teams and, consequently, the integration of the works developed. Our proposal aims at this integration, i.e., to overcome the abovementioned problems.

We started by identifying the research motivation by sharing the proposal with all personnel, edifying the issues we wanted to address and the expected benefits, involving and motivating people. We identified the main concepts in accordance with our proposal and populated a single and shared common repository tool to support all concepts and their relations. A service orientation provided a single guidance for both functional divisions, diminishing misalignments and maintaining up-to-date information about the organizational “as-is.” The results were not only very good, but also better and faster than expected.

7 Evaluation

The crucial integration point between both approaches, EA and ITIL, is the services delivered, which is the reason for an organization’s existence. This common focus enables an integrated approach, maintaining the EA paradigm aligned with ITIL principles based on SOA. This answered our research question number one: “Which is the pivotal point between the two approaches?” We defined the pivotal point as the services delivered that are based on SOA.

The integration encompassing the relation between EA and ITIL requires a shared and single repository for the alignment between service management and EA artifacts. Otherwise IT is a collection of artifacts to meet technical requirements. The single repository answered our research question number two: “How to merge both approaches?” Thus, both approaches are merged, keeping the EAs, ITIL’s service life cycle, and the meta-model for services. The third question research “How to keep the merged information up-to-date?” is answered by the need to share information among functional divisions, using ITIL processes to keep information updated, through IT service management support processes.

ITIL principles and processes guarantee the update and consistency of information with standard processes like Configuration Management and Change Management, respectively, which ensure the reliability of the data that were recorded and accessed in the common repository and allow us to see the effects of the changes. The data repository was no longer a mere database with CI and their relationships, nor an architectural artifacts map of the “as-is” organizational state. Instead, in this approach, it encompasses all EA principles in an operational way.

8 Conclusion

This paper provides a research over the integration between Enterprise Architecture and IT service management. Being considered the two most important approaches in IT governance domain, we conducted an overview of the research made relating these two frameworks. During the course of our research, it became clear that the integration between ITIL and EA is a subject at its very beginning. We found a small number of studies and none solved the problem in a satisfactory way. Considering that both frameworks are complementary, but no integration proposal answered our research questions, we developed a new integration conceptual proposal based on services through a SOA paradigm.

Having answered our research question by providing a solution to the secondary questions, we may conclude that our proposal was verified, making a contribution to fill in the lack of research in Enterprise Architecture and IT service management integration. As shown in this paper, a relation between ITIL and an EA can be set, providing strong arguments for the existence of only one repository and avoiding duplication of efforts. The consolidation of both approaches in the same platform is imperative to achieve an improved alignment, while reducing the effort that would result from managing similar information in two distinct repositories.

We believe that our research is a contribution to organizational engineering, because it provides a proposal to integrate EA and ITIL initiatives. Therefore, we hope this study will be a key addition to academic efforts by bridging service management through architecture paradigm.

Another area of future research is the identification, relationship, and modulation of processes linked to services. Besides the existence of modulation standards (e.g., BPMN) to design business processes, the accuracy and subjectivity of modulation depend on the level of the people’s organizational maturity, which should be avoided with a modulation maturity-independent framework.