Keywords

1 Introduction

Information Technology Service Management (ITSM) is a paradigm for the management of Information Technology (IT) and Information Systems (IS) that promotes the idea of looking upon the IT organization as a service organization. ITSM is rooted in the Information Technology Infrastructure Library (ITIL), a best practice framework initially composed in the 1980 s by the British Central Computing and Telecommunications Agency (CCTA). A second edition, issued in 2001, was broadly perceived in practice and made the ITIL a de-facto standard. The third edition of the ITIL, issued in 2007 and updated in 2011, even found its way into the ISO/IEC 20000 making the ITIL a somewhat de-jure standard on an international scale. Hardly any other standard has influenced the practice of IT management in general and IT operations in particular to the extent the ITIL did. It is not surprising then that the ITIL has found its way into academic IS curricula and stimulated an academic debate [1].

Research so far has focused on the diffusion of the ITIL in practice. Studies by Kemper et al. [2], Hochstein et al. [3], Tan et al. [4], Marrone and Kolbe [5] as well as Marrone et al. [6] document broad adoption of the ITIL. The benefits that organizations associate with the implementation of the ITIL are, for example, a higher overall service quality, a higher first call resolution rate, or a reduction of downtimes. Remarkably, the benefits perceived seem significantly diminish with the level of maturity achieved [5].

In addition, studies that dive deeper into organizational practices reveal that many of the organizations still struggle with the main ideas underlying IT service orientation. For example, a study by Winniford, Conger and Harris [7] found that IT executives, despite claiming to have successfully introduced the ITIL into their organization, had difficulties explaining what an IT service is and struggled to give examples. Additional case studies and action research [8,9,10] reveal that organizations that adopt the ITIL do not necessarily understand and implement the underlying core concepts including, above all, that of an IT service. This is a devastating result, given that the IT service is the “nucleus of the entire ITIL” [11, 12].

A clear understanding of IT services is also a condition sine qua non for any theory development on “IT Service Management”. In fact, the IT service is the core theoretical term of ITSM. But so far, researchers have not been able to clearly define what exactly is meant by the term “IT service”, so that the theoretical kernel of ITSM remains vague [13].

We take this situation as the motivation to investigate the concept of an IT service as rooted in the ITIL and discussed in ITSM in more depths. The objective of our research is to come up with a clear and substantial definition of “IT service”, which is desperately needed for ITSM research. In this paper, we lay out core findings from our research. We start with a theoretical investigation and with a literature review on the definitions of the term “IT service” given in the professional and academic literature in Sect. 2. Using this as a starting point, we dive deeper into the academic discussion on ITSM and the ideas underlying the IT service concept in Sect. 3. Here is where we carve out the distinguishing characteristics of IT services. To demonstrate the definitional power and practicality of our definition, we illustrate its applicability with a real-world example taken from one of our research projects on ITSM (Sect. 4). We close the paper with a short summary and an outlook on future research.

2 IT Services – Omnipresent but Still Ambiguous in the Literature

The empirical basis of our research is a literature review on the IT service concept as used in the academic debate on ITSM. Following the taxonomy of literature reviews proposed by Cooper [14], our review can be characterized as being focused on research outcomes with the goal of understanding a central issue, namely what is meant with IT service in ITSM, by integrating the current academic debate. We do this by synthesizing and consolidating the conceptions we find in the literature. Hence, the organization of our review is conceptual. We do this without biasing our perspective ex ante. Rather, we are open to any interpretation used in academia. The coverage of our literature review is broad. Although it is hardly possible to claim completeness for any literature review, we intended to be as exhaustive as possible in the coverage of the literature. The target audience is, first specialized scholars working on theoretical foundations of ITSM. Second, our research is of value for practitioners struggling with the definition of IT services in their concrete business settings.

In the next subsections, we provide insights into the findings from our literature review. We start with a short introduction into what is understood by the term “IT service” in general before we introduce a more in depth picture of its understanding in the academic debate on ITSM.

2.1 IT Services in General

In the literature, the term “IT service” is used to refer to a broad set of “services” that are (somehow) related to Information Technology. For example, publications in the context of SOA and Web Services tend to define an IT service in a technical way [15,16,17,18]. Other publications that deal with IT Services in an outsourcing and offshoring context use IT service to refer to solutions provided by IT outsourcing providers in general [19,20,21,22,23,24]. Similar definitions are found in publications on the IT service market, which also refer to a diverse set of offerings even including IT consulting, training, and software development as services [22, 25,26,27,28,29,30]. The diversity of IT services we found is also reflected in common IT service taxonomies used for statistical purposes [31,32,33]. These include a diverse mix of activities including “software development projects”, “hardware deployment”, “hardware repair”, “software maintenance”, “software hosting”, “systems integration” as well as “IT hotlines”, “IT consulting”, “IT training”, and “IT outsourcing”. Given this diversity, it is obvious that IT can play different roles in IT services. In addition, many authors do not explain why they look at a “software development project” or a “hardware deployment” as a service. Other authors, in contrast, explain their service understanding in more detail, often by referring to service theory in general [9, 34,35,36,37]. This is particularly true for the academic debate on Service Science which builds strongly on the foundations of service theory in general next to theories from management studies and engineering [38, 39]. We also see the value of applying the perspective of the general theory of services (GTS) to IT services. It turned out to be particularly helpful in making sense of the different interpretations of IT services that we found in the literature and in explaining how they differ.

GTS looks upon services, above all, as immaterial and intangible goods. Immateriality is the reason that software is often subsumed under the roof of “IT services” [32]. However, the intangibility of services requires a physical object for the service to manifest. GTS refers to this object as the “external factor”. External factors can be the service customer herself as well as people in her aegis or goods in her property. Everyday examples are a haircut, gardening services or a carwash. In many cases, the term “IT service” refers to services that have information technology facilities in the property of the recipient as external factors [26, 29, 40,41,42,43]. A simple example is a computer repair, with a broken computer being the external factor. Two further examples are an individual software development project and IT consulting. In the first case, the external factor is a customer problem defined in a software requirements specification. In the second case, the external factor is a management need to be addressed in a specific business context.

An immediate consequence of intangibility is that services cannot be stored so that the production and use of a service are coincidental. This condition, the so called “uno-actu-principle”, requires that a service provider needs to hold available all the production factors necessary to render the service on demand for service customers. GTS refers to these internal production factors as “potential factors”. Business Process Outsourcing (BPO) or Software as a Service (SaaS) may serve as examples [32, 33]. In both cases, IT systems are the core production factor deployed to deliver the service, i.e. to execute business processes automatically or to provide a user with software functionality. Such IT services that make use of hard- and/or software as potential factors are often referred to as “IT-based services” in the literature [37, 44].

2.2 IT Services in the Context of ITSM

Equipped with a GTS-based understanding of IT services, we analysed in more detail academic publications in the field of ITSM and ITIL. We identified the Information Systems discipline as central to the debate on ITSM. Hence, we sought for academic publications in Information Systems and its “mother disciplines” Business Administration and Computer Science. We chose the EBSCO databases “Academic Search Premier”, “Business Source Premier”, “EconLit with fulltext” and “Information, Library and Technology Abstracts” (that include also the Senior Scholars Basket of Eight) for the IS and BA disciplines, as well as ScienceDirect, EmeraldInsight, ABI/Informs and Springer to get access to relevant publications in these disciplines. In addition, for a better coverage of publications from Computer Science, we also included IEEExplore. Finally, the ECONIS catalogue of the German National Library was used to complement journal and conference publications with book publications in the field of IS. We searched these data bases very broadly for occurrences of the term “IT service” in different notations using the search string <“IT-service” | “IT service” | “IT-Service” | “IT Service” > in title and/or abstract. This search led to a sample of 328 results that we checked manually for being related to ITSM or not. This way, we excluded, for example, technical contributions on Service Oriented Architectures (SOA) or web services as well as general publications on IT outsourcing and the IT market. This left us with a remaining subsample of 178 publications that could be of relevance for our topic. Of these, the majority was published on conferences (49%) and on smaller workshops (13%). The fact that only 2% of the publications had found entrance into the journals can be seen as an indication for a preliminary state of theory development on ITSM. In addition, we found that the academic debate on ITSM is more vivid in middle Europe and Scandinavia than in the USA and the UK.

Our literature review revealed that most publications (77%) totally omit defining what they mean by an IT service [5, 56,57,58,59]. Other publications (4%) simply refer to the definition given in the ITIL [7, 60,61,62,63,64]. This left us with only 13 out of 178 publications that have a dedicated definition of “IT service”. However, a short look at Table 1 reveals that these definitions are neither unambiguous nor concise, but differ substantially in both definiendum (IT product, IT performance) and definiens (IT functions, performances, service components). In Table 1, we have organized the definition on a continuum depending on whether they emphasize more “what” IT services are “good for” while others try to explain “how” IT services are “composed or produced” as indicated on the left of the table.

Table 1. IT service definitions in the literature
Full size table

The least common denominator of the definitions in Table 1 is perhaps that they assign “IT” or related concepts such as “IT components”, “IT functions”, or “IT performances” the role of a potential factor. Hence, to use the terms of Böhmann and Grawe and Fähnrich [37, 44], IT services are always “IT-based services”. However, the scope of IT-based services is still large: a data centre service, a computer-supported health check and market research supported by databases and software for statistical analysis are included alike.

In the next section, we set out to distinguish the concept of “IT services” in ITSM from other, broader interpretations. For this purpose, we will refer to this concept with the term “ITility Service” in the following chapters. We have chosen this term because of its phonetic picture that corresponds to that of the term “utility”. This correspondence is intended to emphasize two basic features: First, ITility Services are utilities in the sense that they are useful and generate (business) value for a service customer. Second, the way that customers are served with ITility Services is sometimes envisioned in ways that are similar to how utility companies serve their customers with gas, water, and electricity [65]. And as a nice side effect, “ITility” can also be associated with the ITIL as the initiator and stimulator this field of research. In the next section, we introduce the characteristics of ITility Services and relate them to discussions in the academic literature.

3 Towards a Concise Definition

In this section, we put forward six characteristics that we believe make a concise and relevant definition. We demonstrate how each characteristic is more or less rooted in the ITIL, and go on by substantiating it with the academic discussion on ITSM and emerging theory development.

3.1 Intangible

Above all, a service is intangible, so that it requires an external factor to manifest itself and generate a business value. This important characteristic of ITILity services is broadly shared throughout the academic literature on ITSM [2, 11, 45, 49, 55]. Yet there is little consensus on what this external factor actually is. The ITIL does not explicitly elaborate on this, but simply says that an IT service “[…] supports the business processes of one or more customers” [66]. However, it is misleading to look upon the business process itself as an external factor since ITility Services do not transform business processes (as opposed to, for example, change management consulting services). Rather than being altered through an ITility Service, business processes themselves transform information objects. These objects are already well known from business process management research where they are called “business process objects”. Rosemann [67] characterizes business process objects as “process-shaping objects” that “drive the process flow” in that their status demands for the execution of specific processing functions. Invoice processing is a good example with the invoice being the formative (information) object for the whole business process. A typical ITility Service in this example could entail the processing of a customer master data record together with ordering data for writing invoices.

In line with the ITIL, most researchers agree on the fact that ITility Services support business processes, thus implicitly pointing to business process objects as the external factor. Zarnekow et al. [45] go one step further when also considering the products that an organization offers to its customers as external factors of ITility Services. They give the example of an electronic railway ticket which is part of a railway company’s end customer product/service. The authors argue for the relevance of business product objects as external factors by highlighting the immediate value contribution to the company’s products and services. We acknowledge that the external factor of an ITility Service can be both a business process or business product information object. Hence, we refer to this object more broady as business object.

3.2 Generating Customer Value

ITility Services generate value by processing business objects. The ITIL explains that this value is produced “[…] by facilitating outcomes customers want to achieve” [66]. Service customers are the organizations or organizational units that order and use the ITility Services. But how can organizations profit from an ITility Service? In most cases, it is through human actors that perform business task and execute business processes on behalf of the customer organization. In the ITIL, these human actors are referred to as “users” of an ITility Services [68]. Users invoke an ITility Services, for example, by pressing a button or entering a command [69]. In some cases, they must feed in information manually before they can invoke the service, for example by filling an entry mask. In very rare cases, where business processes are fully automated, the actors invoking an ITility Service can also be machines.

Irrespective of how an ITility Service is triggered, it is on behalf of a customer organization and to its benefit. An ITilty Service may be utile in the eyes of a user or a group of users. These users act on behalf of a customer organization that ultimately appropriates the business value from the ITility Service.

3.3 Provided by Means of an IT-Based Infrastructure

Our analysis so far has told us that the external factors of ITility Services are information objects. Users play an important role in feeding in information objects and triggering their processing. But what is the role of “IT” in rendering ITility Services? The ITIL uses the term “IT” as an umbrella term for a broad set of components including “computers, telecommunications, applications and other software” [66]. Zarnekow et al. [45] distinguish these components in more detail into application systems, servers, storage media, wireless and wired networks as well as desktop systems. These components are “executing” service [70]. Moreover, researchers highlight that these components are highly interrelated and strongly interact with each other to produce the intended service outcomes. It is for this reason that Zarnekow et al. refer to these IT components as “production infrastructure” [45]. They propose to arrange this infrastructure into homogenous layers, with lower-level components providing inputs to higher-level components. On the lowest layers they see the technology resources like server hardware and storage components, which in turn can be used by system software components including middleware and operating systems. These in turn provide services to application platforms (e.g. workflow management and data management systems) and application systems (e.g. enterprise resource planning, office) which implement the business logic for processing information objects.

3.4 Produced in an Industrial Fashion

The ITIL explains that ITility Services are produced “by information technology” in combination with human actors (“people”) within defined “processes” [66]. Rodosek [51] looks upon IT facilities and people as the “elements” that (ITility) services are made of. Accordingly, IT and people can be looked upon as the essential “potential factors” in the production of an ITility Service. This is analogous to industrial production, with IT representing the production equipment and the “people” representing the workforce needed to operate and supervise the technical equipment. In addition, the idea of industrialization is associated with production processes that are standardized, automated and specialized in order to reduce production costs and to increase the production speed and the quality of the products [71]:

  • Automation refers to substitution of manual labour by machines or technology in industrialized production processes. In effect, automation leads to production processes that are mainly executed, supported, and controlled by machines. In the case of ITSM, these machines are represented by the IT-based production infrastructure introduced in the above section.

  • Automation in turn furthers specialization by first dividing labour between machines and humans and second by differentiating the tasks and responsibilities of human actors. Specialization results in human actors with dedicated skills performing highly specific tasks.

  • A third trait of industrial production is standardization. The idea is that reductions in unit cost are bigger the higher the number of products produced (product standardization). The reason is that standardized products can be produced through standardized procedures, which in turn allow for high levels of specialization and learning effects (economies of scale).

The ITIL supports the idea of product standardization by distinguishing between “business services” (that are assumed to deliver “products” to end users and customers) on the one hand and “infrastructure services” (that can be compared to “upstream products” or technical “product components” in industrial production) on the other hand. The ITIL also promotes the standardization of processes. Well-known processes put forward by the ITIL are “Technical Management”, “Application Management”, “Event Management”, “Incident Management”, or “Problem Management”. The ITIL also proposes specialized job profiles with dedicated responsibilities and skill requirements such as “Capacity Manager”, “Incident Manager”, “Continuity Manager” or “IT Operator”.

While the ITIL does not explicitly highlight the “industrial production” of IT services as a definitional feature, this characteristic is among the most prominent ones in the academic discussion on ITSM [9, 72, 73]. Hochstein [74] proposes processes for planning ITility Services in an industrial fashion based on the assumption that these services can be standardized and that their production can be automated. Zarnekow [75] shares these assumptions and proposes to furthermore apply methods for industrial production planning and control to tasks such as the planning of production sites, programmes, and for adjusting production volumes. Traugott [76] and Hallek [49] further propose to apply techniques from industrial production planning such as service trees, part lists, and working plans to the production of ITility Services. Moreover, Probst [77] as well as Hallek [49] propose semi-formal models to describe standardized ITility Service processes. These works culminate in the proposition of an excellence model for producing ITility Services in an industrial fashion [78] and give rise to the vision of an “IT factory” [65]. However, this research largely remains on a conceptual level and fails to provide much empirical evidence for the efficacy or at least the feasibility of the propositions made. In fact, empirical studies indicate that practice is far from implementing such concepts [9, 74].

3.5 Mass-Customized

Customer orientation on the one hand (Sect. 3.2) and industrialization of ITility Services on the other (Sect. 3.4) involve an inherent contradiction: meeting individual customer needs and standardizing ITility Services (and their production) are conflicting goals. The ITIL does not give much guidance on how this immanent conflict can be resolved. Fortunately, this conflict is already well-known in industrial production and has been successfully addressed with an approach called “mass-customization”. This approach has been introduced by Davis [79] and further developed by researchers like Hart and Taylor [80]. The central idea of mass customization is to combine standardized pre-fabrication and individualized finishing to be able to offer end-products to customers that match their individual needs better than mass products but that are at the same time much cheaper than custom-made products.

At the heart of mass customization lies the concept of modularization, that is mass-customized products are to be composed of standardized components. These components, called modules, are supposed to be combined flexibly in ways that allow for tailoring end-products to the specific needs of individual customers. There are two dominant approaches to achieve this: One is the flexible combination approach which entails much complexity as it necessitates predefined and standardized interfaces of each module. Hence, this approach quickly encounters technical limits [81, 82]. The other approach assumes a common core product, the so-called product platform, that is extended with add-on functionality by attaching optional modules. Compared to the flexible combination approach, the platform approach is less flexible but more manageable and thus more practicable. Both approaches have been applied to ITiltiy Services.

Rudolph [53] builds on a platform approach for mass-customization. She looks upon ITility Services as bundles of so-called “service modules” which she further distinguishes in “standard modules” and “optional modules”. Moreover, she suggests that an ITility Service includes at least one standard module as a core which can also be thought of as a service platform. This core (or platform) can be enriched by a set of optional modules that allow for tailoring ITility Services to the specific needs of customers. Grawe and Fähnrich [44], in contrast, favour the approach of flexible combination. They propose to compose ITility Services out of reusable components and postulate detailed guidelines for product composition to ensure a demanded quality, meet capacity requirements, and to enforce technical compatibility. The authors call this approach “mass configuration”. Brocke, Uebernickel and Brenner [83] consider both the platform and flexible combination approach with respect to their applicability to the mass-customization of ITility Service level agreements. They also discuss possibilities to combine both approaches.

The academic debate on the industrialization and mass-customization in ITSM is closely linked to Service Science and, in particular, Service Engineering. The latter is a research field within Service Science concerned with the application of systematic, engineering-like methods to the design of services and service systems [84,85,86]. Service Engineering does not specifically focus on ITility Services, but has a broader interest in the use of IT for delivering services. Hence, some authors look upon ITSM as being “a subset of Service Science” [57]. However, many researchers in this field have a specific interest in IT-based services [37, 44, 87]. Some of their ideas and propositions concerning the standardization of service products, the reuse of service modules, or modular service architectures have also been adopted to ITility Services.

3.6 Provided Carefree to the Customer

The production of ITility Services is a complex process that involves multiple IT facilities and a large set of professional personnel operating it (Sects. 3.3 and 3.4). However, the customer should not be burdened with this complexity. Instead, he should be able to take advantage of the services “without the ownership of costs and risks” [66]. This in turn makes rendering ITility Services “carefree” for the customer. The provider must deal with the challenges, costs and risks of producing them. In return, the provider is entitled to charge the customer with a service fee that accounts for the costs and risks of service production and may also include a profit margin.

In line with the ITIL, researchers in the field of ITSM share the assumption that the production of ITility Services should be transparent to the customer and the users. Jouanne-Diedrich, Zarnekow, and Brenner hold the view that the business departments which order the service “are not interested in how these are provided but only in that they generate a value at reasonable costs” [73]. Rudolph adds that “technical details such as the equipment used and the configuration of application or database servers does not matter and thus does not need not to be exposed to customers and users who should instead be well informed about the service functionality and potential contributions to the business” [53]. Zarnekow et al. even demand that “(…) those who receive the services should be shielded from the technological complexity underlying the production of the services” [45]. Only the provider of the service needs to have authorization and an overview over the equipment and processes involved in service production since he bears the risks of service production [48].

The idea of carefree ITility Services is also supported by the postulate of a single face to the customer [44]. Neither the customer nor the users of ITility Services want to get burdened with technical details and multiple contact persons, but they want to have one contact point which is, according to the ITIL, a responsible service manager and, respectively, the central service desk [66].

4 Implications for Developing IT Service Level Agreements

Our understanding of an ITility Service as put forward in the previous section has an immediate impact on the development of Service Level Agreements. In general, a Service Level Agreement (SLA) is an agreement between a customer and a provider on the provision of a service. A SLA is output based in the sense that it defines what kind of service (service subject) the customer will receive in which quality (service levels) rather than how the service is rendered. Karten [88] defines a SLA as “a formal negotiated agreement which helps to identify expectations, clarify responsibilities, and facilitate communication between a service provider and its customers.” SLAs can be used between two legally independent parties or by two different parties within the same organization. In the latter case of external SLAs, formal contracts are written up and hence include legal regulations.

In very general terms, an IT SLA is characterized by the fact that one party in the agreement is an IT service provider. In more detail, Berger [89] defines an IT SLA as a formal and written agreement between a service customer and a service provider for a defined period of time. The provider confirms rendering a service specified in scope and quality while the customer, in response, agrees to make a compensation payment.

However, despite their huge practical importance, research so far has not paid much attention to IT SLAs [89]. Recommendations on what to include in an IT SLA are scant [89,90,91,92,93]. Table 2 presents an overview of three recommendations that go beyond simple lists of attributes and also suggest a structure.

Table 2. Contents of IT SLAs in the academic literature
Full size table

The recommendations in Table 2 differ significantly in how they structure an IT SLA and in the attributes they include. This diversity is partly owed to the different types of IT services that can be subject to an SLA (Sect. 2.1). Unfortunately, specific recommendations for designing SLAs in an ITSM context are still missing. The only source of advice for practitioners is an example from the ITIL [94], which does not recommend any structure, but simply provides a long list of attributes without justifying them.

Moreover, as a closer look reveals, some attributes seem to be selected randomly. For example, attributes like “batch operating times” or “printing” are relevant only in specific cases where batch processing and printers are involved. Moreover, attributes such as “continuity”, “security”, “change management”, and “reporting and review” are defined in terms of the processes executed by the provider rather than in terms of what the customer receives. However, a certain procedure for “change management” on the provider side cannot be immediately translated into certain service quality for the customer.

More fundamentally even, the ITIL example does pay only little attention to defining the service itself. It recommends to give a short service description without giving much guidance on how to define the service concisely. The ITIL simply suggests describing the “key business functions” and “deliverables” without giving further explanations. Only “if appropriate”, these shall be complemented with a description of the “minimal functionality to be provided”. Hence, with respect to the service definition, the ITIL does not give any specific advice for specifying ITility services if compared to the general IT SLA recommendations (Table 2).

As opposed to the little attention payed to defining IT services in the literature, an empirical study by Trienekens, Bouman and van der Zwan [95] indicates that practitioners often struggle with clarifying the subject of an IT service in SLAs. We look upon this problem as being particularly severe for ITility services which are more difficult to grasp because of their supporting nature (Sects. 3.1 and 3.2) and technical transparency (Sect. 3.6). Hence we propose to start the SLA with a detailed definition of the service subject comprised of four attributes. Here, we propose to start with defining the business processes or products supported by the ITility Service (Sect. 3.1). This attribute easily allows customers to figure out whether the service can be used in their organization and if so, where it can be used. ITility services provide value to the customer by supporting the business. Hence, after the business processes targeted by the service have been determined, we propose to specify the value provided by the service in more detail (Sect. 3.2). For example, an ITility service that supports writing invoices might have value to the customer organization by speeding up the billing process, reducing errors, and facilitating invoice and payment tracking. A further clarification of the service can be achieved by determining the business objects processed (Sect. 3.1). In the invoice example, these objects are, above all, a customer data set, a delivery data set, and the invoice as an outcome. Finally, to complete the description of the service, we recommend providing more detailed information on the functionality provided by the service. In the example above, core functions might be composing invoices, printing invoices, and tracking the payment process. A negative delimitation of the functionalities not included in the service might also help to clarify the scope of the service (compare Berger [89]).

The service subject (what?) is the point of reference for defining the service quality (how good?). The IT SLA literature (Tables 2 and 3) suggests a set of quality attributes such as, above all, service hours, response time, processing capacity, availability, reliability, recovery period, security. However, the proposals do not distinguish quality attributes in the three different service dimensions (Sect. 2.1), namely the result dimension, the process dimension, and the dimension of potential factors. In Sect. 3.6 we have argued that ITility services emphasize the results dimension (i.e. what the customer gets) over the process and potential factor dimensions (i.e. how the service is produced). In line with this, an SLA for an ITility service should favour result-oriented quality levels such as service hours, availability, reliability, response and processing time. The process-oriented quality attributes that are prominently featured in the ITIL example (e.g. security, continuity, change management etc.), should only be included in particular cases and for specific reasons. They can help in facilitating the co-operation between customer and provider (e.g. to foster common working practices) or in ensuring compliance. The same is true for potential-oriented quality attributes (e.g. compliance with security standards or professional qualifications).

Table 3. Sample SLA from the ITIL
Full size table

Both the service subject and the quality attributes introduced so far relate to the core ITility service which is automated (Sect. 3.4) and produced by means of an IT-based infrastructure (Sect. 3.3). In addition, the SLAs summed up in Tables 2 and 3 include attributes that refer to the support provided to the users of the core services. Support, however, is an add-on to the core service that facilitates its use. As such, it is largely independent from core service (also see [89]). This can easily be seen from the fact that different support conditions can be applied to one and the same core service and the same support conditions can be applied to multiple core services. Hence, we propose to specify the support service in a separate section of the SLA. The literature assumes that the subject of support (assistance in using the service, support in case of service breakdowns) is well-known and does not need further elaboration in an SLA. But irrespective of whether the subject of support needs further clarification or not, there is still the need to define the quality expected from the support. The support quality should again focus on the result-dimension of the service. Typical attributes proposed in the literature are availability, response time, resolution times etc.

So far, we have introduced a very basic service. According to the ITSM paradigm, such a basic service should be further adaptable to the specific needs of different customer groups. The method of choice for this purpose is mass-customization, which can be achieved either through preconfigured versions or as optional modules to the base service (Sect. 3.5). Mass-customization can be applied to the service scope as well as to the quality of the core service and of support. Accordingly, our SLA allows for variants in all three SLA sections introduced so far.

The three SLA sections “Core Service”, “Core Service Quality”, and “Support Service Quality” allow for a thorough specification of an ITility service. Irrespective of this, customers need additional support in figuring out whether services fit to their needs or not. ITSM suggests developing IT Service Catalogues for this purpose [94]. Such catalogues should give a carefully curated and organized overview over services that might be of interest to the customer. We support the view that customers cannot be expected to read complete SLAs just for the purpose of finding out whether a service might be of interest to them or not. Hence, the necessity to assist the development of Service Catalogues as well as the general ITSM postulate of customer-orientation has led us to include a “Service Header” in an SLA upfront. This header is intended to give a quick orientation by expressing the essence of the SLA. It can be compared to a concise management summary, which answers questions like: Is the service relevant for my organization? Does it meet my business needs? Who are the users addressed by the service? The header includes a unique name for the service, a short description of the service subject and scope, as well as the targeted customer and user groups.

Table 4 displays the IT SLA stub resulting from our theory-based understanding of an ITility service. Our stub provides a clear structure and, as a comparison with Table 2 reveals, covers the central SLA attributes discussed in the literature. What is not included in our SLA stub are attributes referring to the communication and cooperation between service provider and customer (e.g. points of contact, reporting and escalation procedures). We have left out these attributes because our interest was first of all in demonstrating the impact of our specific understanding of ITilty services, which is not immediately related to communication and cooperation. Further SLA attributes that we did not dwell on such as document versioning and a glossary relate to the SLA document itself. Our SLA stub also does not include pricing and legal aspects. The reason is that these apply only in the specific case of external SLAs, where the provider is outside of the customer’s organization.

Table 4. SLA stub for an ITility service
Full size table

5 Conclusions and Future Research

In this paper, we have put to discussion a definition of IT services for the particular context of IT Service Management (ITSM). For the purpose of distinguishing them from IT services in other contexts, we refer to such IT services with the artificial term “ITilty services”. Based on both the general theory of services and the theories of industrial production we have proposed six distinguishing features of ITility services: They are intangible, provide a value to customers, are produced in an industrial fashion by means of an IT-based infrastructure, their production is transparent to the customer, and they are mass-customized to better meet customer needs.

To demonstrate the impact and relevance of our definition, we have applied it to the definition of a Service Level Agreement. The results document that our definition makes a difference: The ITility SLA stub proposed in Table 4 clearly marks itself off from the IT SLAs proposals given in the academic literature. It provides a clear structure and distinguishes explicitly between the core services and support. It also favours defining service outcomes over the processes and potentials factors used for rendering the service. Finally, it accounts for a sophisticated customization of the service scope, service quality, and support.

We have also been able to assess the practicability of our definition in industry. We applied our definition of an ITility Service in a German publishing company that worked on the definition of a company-wide IT Service Catalogue. In this project, we were able to define 32 ITility Services that finally found their way into the catalogue. Motivated by the success of this project, we are currently assessing our ITility Service definition on a broader scale in a project with a German University. The central IT unit of this university has been working on initiatives to develop a university-wide service catalogue from 2010 on. The major motivation for developing such a service catalogue was to get an overview of the spectrum of IT offerings and services across the university, including the central university data centre and decentral IT units. An additional motivation was to ensure a high service quality and to be able to demonstrate it to customers and users. However, the central IT unit’s initiatives encountered severe difficulties in establishing consensus on what actually an IT service is or should be. These can be exemplified by IT services from the initial service catalogue like “Lectures on Office Applications”, “Provision of LAN nodes”, “Distribution of IT Handbooks” or “Rental of Photo Cameras”. Given these difficulties, we started a joint research project in 2016. By now we have been able to identify a set of 30 core services for the university with the help of our definition. We are currently working on the negotiation of these services in SLAs with different departments and user groups in the university. We used a template similar to that displayed in Table 4 for this purpose. The project is still running, but is encouraging so far [96]. Our experiences suggest that our definition of an ITility Service is very helpful for practitioners to better understand the nature of ITility Service. It also seems to be conducive in identifying service candidates and agree upon them in SLAs.