AHP evaluation of rigorous and agile IT service design-building phases-workflows in data centers

The design-building of IT services in data centers has been historically conducted by applying rigorous IT service design-building phases-workflows. Consequently, relevant research has been conducted upon these rigorous phases-workflows to provide theoretical foundations and practical guidance to IT service design-building architects. However, the current dynamic business-governmental environment is demanding agile approaches, and research from this perspective is still very scarce. This research, thus, aims to provide an updated review and quantitative evaluation of the main rigorous (ITIL v2011, CMMI-SVC v1.3, and ISO/IEC 20000-1:2018) and main agile (ITIL v4, VeriSM, and ISO/IEC 29110-4-3) IT service design-building phases-workflows. For this aim, we conduct a conceptual review research methodology enhanced with an analytics hierarchical process (AHP) method to assess quantitatively how well these six IT service design-building phases-workflows fit two theoretical expected rigorous and agile IT service design-building phases-workflows pro formas. We found that the ITIL v2011 and CMMI-SVC v1.3 phases-workflows fit the rigorous pro forma with a high level, and the ISO/IEC 20000-1:2018 fits a moderate level, whereas all these three ones fit a low level the agile pro forma, as it was expected. ITIL v4 and VeriSM were found to fit a high level the agile pro forma but the ISO/IEC 29110-4-3 fits a moderate level. Unexpectedly, ITIL v4 and the ISO/IEC 29110-4-3 fit a moderate and moderate levels the rigorous pro forma, but VeriSM fits a low level as it was expected. Hence, we can conclude that ITIL v4 and VeriSM provide the most agile IT service design-building phase-workflow, and CMMI-SVC v1.3 the most rigorous one. The ISO/IEC 20000-1:2018 and ISO/IEC 29110-4-3 standards are still aligned to the rigorous approach, and ITIL v4 exhibits a dual moderate rigorous and high agile profile. Hence, this research provides ITSM professionals with an updated analysis useful to guide the selection and application of the IT service design-building phase-workflow—rigorous or agile one—in data centers. This research also contributes to the IT service design-building literature with updated insights and proposes specific research avenues to advance our scientific knowledge on how to design-building IT services.

Data sharing not applicable to this article as no datasets were generated or analyzed during the current study.

Authors and Affiliations

1. Research Lab DataCenter, Autonomous University of Aguascalientes, Aguascalientes, Mexico

   Paola Yuritzy Reyes-Delgado, Manuel Mora, Fen Wang & Jorge Marx Gómez

2. Information Systems Department, Autonomous University of Aguascalientes, Aguascalientes, Mexico

   Paola Yuritzy Reyes-Delgado & Manuel Mora

3. Information Technology & Administrative Management Department, Washington Central University, Ellensburg, WA, USA

   Fen Wang

4. Informatics Department, Carl von Ossietzky University of Oldenburg, Oldenburg, Germany

   Jorge Marx Gómez

Corresponding author

Correspondence to Manuel Mora.

Conflict of interest

The authors declare that they have no conflict of interest.

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Appendix 1

See Tables [15, 16]

Appendix 2. Review of the six IT service design-build phases-workflows

2.1 Rigorous IT service design-building phase-workflow in ITIL v2011

In ITIL v2011 [9], a service is defined as a “means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.” An IT service is defined as a “service provided to one or more customers by an IT service provider, based on the use of IT and supports the customer's business processes, and is made up from a combination of people, processes and technology and defined in a Service Level Agreement.”

In ITIL v2011 [9], the concept of IT service architecture design is reported as a Service Composition Diagram and a Service Relationship-Dependence Model. In Fig. 5 we report an adaptation of both diagrams. The core elements derived from both diagrams are the following: (1) business unit, (2) business service, (3) business process, (4) IT service (service utility, service warranty (SLAs)), (5) assets/resources (infrastructure (HW, SW, DBMS, NW), environment, data, applications), and (6) assets/capabilities (IT processes, support teams (OLAs), suppliers (UCs)). The derived interrelationships are the following: (R1) a business unit delivers business services; (R2) a business service is made up of business processes; (R3) business processes (and lately business services) are supported by IT services; R4) an IT service is characterized by service utility and warranty parameters; (R5) an IT service is made up of assets/resources and assets/capabilities; (R6) assets/resources are infrastructure (HW, SW, DBMS, NW), environment, data, and applications; and (R7) assets/capabilities are IT processes, support teams and suppliers.

ITIL v2011 service composition model and service relationship-dependence model

Full size image

In ITIL v2011 [9], one of its five main phases is IT service design. This fact suggests the relevance of design activities for fulfilling the expected quality of service levels to be delivered. In ITIL v2011 design is an activity that identifies requirements and then defines a solution that is able to meet these requirements. IT services must be carefully planned and designed in order to be deployed and operated as expected. An informal design process cannot assure performance, risk-based, security and cost-effective guarantees to users. Design IT services helps mainly to avoid costly system disruptions in operational settings caused by design flaws, and to produce the expected performances. ITIL v2011 indicates that service design provides guidance “for the design of appropriate and innovative IT services to meet current and future agreed business requirements” [9, p.4]. Service design must consider the following elements: business process to be supported, the service itself, SLAs/SLRs, infrastructure (all of the IT equipment necessary to deliver the service to the customers and users), environment (the environment required to secure and operate the infrastructure), data, applications, support services, operational level agreements (OLAs) and contracts (any underpinning agreements necessary to deliver them), support teams, and suppliers.

ITIL v2011 service design phase includes the following processes: Service Catalog Management, Service Level Management, Capacity Management, Availability Management, IT Service Continuity Management, Information Security Management, and Supplier Management. ITIL v2011 considers five dimensions of IT service design: service solutions, management information systems and tools, technology and management architectures, processes, and measurement methods and metrics. ITIL v2011does not report a specific IT service design process but suggests a set of activities that pursue a design goal. These activities are: (1) Identifying service requirements; (2) Identifying and documenting business requirements and drivers; (3) Designing service solutions; (4) Evaluation of alternative solutions; (5) Procurement of the preferred solution; and (6) Developing the service solution.

2.2 Rigorous IT service design-building phase-workflow in CMMI-SVC v1.3

In CMMI-SVC v1.3 [10], the concepts of service and service system are explicitly defined in the glossary. The particular concept of IT service is not reported. A service is a product that is intangible and no storable delivered through service systems designed to satisfy service requirements. A service system is defined as an integrated and interdependent combination of service component resources that satisfies service requirements. In CMMI-SVC v1.3, a service system includes everything required for service delivery as such work products, processes, facilities, tools, consumable and human resources (employees and service customers during the service delivery occurrence).

In CMMI-SVC v1.3 [10], an explicit IT service architecture design is also not reported. Similarly to ISO/IEC 20,000, a high-level service model can be derived from several insights. Figure 

IT service architecture design interpreted from CMMI-SVC v1.3

Full size image

Fig 6 reports an interpretation of it. From several diagrams reported in the full CMMI-SVC v1.3 document, Fig. 6 can be identified the following core entities: (1) customer/end user, (2) IT service, (3) IT service value, (4) deployed IT service system, (5) establishing and delivering processes (STSM, SSD, SST, SD, and IRP), and (6) managing services processes (REQM, CAM, SCON, WP, and WMC). The derived interrelationships are the following: R1 a customer/end user uses an IT service; R2 an IT service delivers IT service value; R3 an IT service is delivered through a deployed IT service system; R4 a deployed IT service system is established and delivered through a set of processes; R5 a deployed IT service system is managed through a set of processes; and R6 a set of processes use services components or resources for its execution. In particular, CMMI-SVC considers a service component as a resource required for a service system to successfully deliver services and includes transient resources (e.g., owned by users or third parties but used during the service occurrence). Infrastructure concept is also used for service component resources that are tangible and permanent in the service system. A service system consumable is a resource whose capacity level is reduced or depleted during the service occurrence. For CMMI-SVC v1.3, people is not a consumable but their labor time does.

In CMMI-SVC v1.3 [10], there are four process categories: Support (SUP), Process Management (PRM), Project Management (PM), and Service Establishment and Delivery (SED). The design process is explicitly reported in the Service System Development process, which is part of the SED category, where design refers to “the definition of the service system’s components and their intended set of relationships; these components will collectively interact in intended ways to achieve actual service delivery” (idem, p. 448). The SED category has five processes: Strategic Service Management (STSM), Service System Development (SSD), Service System Transition (SST), Service Delivery (SD), and Incident Resolution and Prevention (IRP). STSM process concerns the identification of the strategic needs of services for a variety of markets, as well as with their business and technical descriptions (e.g., via a service catalog). SSD process concerns the design, building/assembling or service components, and their verification and validation in a development environment. For it, SSD interacts with REQM (Requirements Management process into Project Management category). In SST process, the verified and validated service system is deployed in a production environment, and SD process accounts for the current provision of the services through the released service system. Finally, IRP process addresses the incidents occurred in the IT service system. Hence, SSD is the process directly related with the design of service systems. The purpose of SSD is established as “to analyze, design, develop, integrate, verify, and validate service systems, including service system components, to satisfy existing or anticipated service agreements” (idem, p. 437).

The three specific goals of SSD are the following: SG1 Develop and Analyze Stakeholder Requirements, SG2 Develop Service Systems, and SG3 Verify and Validate Service Systems. From these goals, the first two specific goals address the analysis and design activities in CMMI-SVC v1.3. SG1 covers “the transformation of collected stakeholder needs, expectations, and constraints into requirements that can be used to develop a service system that enables service delivery” (idem, p. 439). SG2 is concerned with “evaluating and selecting solutions that potentially satisfy an appropriate set of requirements; developing detailed designs for the selected solutions; implementing the designs of service system components as needed; and integrating the service system so that its functions can be verified and validated” (idem, p. 446). In CMMI-SVC v1.3 12, specific practices are included in these three specific goals. From them, the three specific practices in SG1 and the first three ones in SG2 correspond to design purposes. These specific practices are the following: SP 1.1 Develop Stakeholder Requirements, SP 1.2 Develop Service System Requirements, and SP 1.3 Analyze and Validate Requirements, in SG1; SP 2.1 Select Service System Solutions, SP 2.2 Develop the Design, and SP 2.3 Ensure Interface Compatibility, in SG2. Additionally, CMMI-SVC v1.3 reports several typical work products as output artifacts of these specific practices.

2.3 Rigorous IT service design-building phase-workflow in ISO/IEC 20,000–1:2018 standard (complemented with ISO/IEC 20000-2:2019 standard)

In ISO/IEC 20000-1:2018 standard [11] (p. 8), the concept of service is defined as “means of delivering value for the customer by facilitating outcomes the customer wants to achieve” but the concept of IT service is used implicitly. Similarly the concept of service system is not explicitly reported. In contrast, the concepts of system and process are relevant. A system is defined as a set of interrelated or interacting elements. A process is a set of interrelated or interacting activities, which transforms inputs into outputs. A service is an intangible resultant from the interaction of activities between a supplier and a customer. An IT service, thus, is a service provided by system of IT processes. In ISO/IEC 20000-1:2018 and ISO/IEC 20000-2:2019 [11, 12], there are not an IT service architecture design reported explicitly. However, it can be derived one from several insights.  

IT service architecture derived ISO/IEC 20000-1:2018 and ISO/IEC 20000-2:2019

Full size image

Figure 7 illustrates the derived IT service architecture design. In this design, the core identified entities are: (1) an organization, (2) a customer, (3) business units, (4) IT services, (5) IT internal or external service provider, (6) technology (hardware, network, applications, systems, environmental systems), (7) external service provider, and (8) suppliers. The derived interrelationships are the following: R1 an organization has customers; R2 customers have one or several business units; R3 business units use IT services; R4 the IT services are delivered by IT internal or external service providers; R5 the IT internal service provider uses technology; R6 the technology is acquired from suppliers.

The design of a new service is part of the Service Management System Operation, specifically the process, Service Design and Transition, which includes the (a) Planning, (b) Design, (c) Construction and transition, of which are detailed below:

Planning uses service requirements, for new or modified services that are determined, and identifies actions to manage change in services prior to implementation. Through analysis and communication with stakeholders, Planning can be refined concurrently with Design, as more specifics and constraints are established (ISO/IEC, 2019). Ten activities are referred to in planning: (1) Determine authorities and responsibilities for design, build and transition activities; (2) Determine the activities and compliance dates to be performed by the organization or other stakeholders, in the design, build and transition; (3) Identify resources to design, build and transition new or modified services; (4) Analyze dependencies or possible relationships with the new or modified service; 5) Identify requirements for testing; (6) Determine the congruence of the project budget with the known effort; (7) Record service acceptance criteria, to know whether a new service or changes to a service have been successfully implemented; (8) Perform risk identification, management, and assessment activities; (9) Determine the expected outcomes of providing the new or modified services; and (10) Identify the impact on the Service Management System, other services, changes and other interested parties [12].

Design activities reflect the new or modified service requirements as originally identified in Planning. There are eight activities relevant to service design: (1) Identify changes or new requirements in human, financial, technical and information resources for the service; (2) Identify the responsibilities and authorities of the parties involved in the operation of the new or modified service; (3) Determine the training, skills and experience needs of the personnel responsible for the provision and operation of the new or modified service. 4) Update the service catalog; (5) Describe changes to measurement systems for performance management; (6) Identify the potential impact on other services; (7) New or required changes to SLAs, contracts or other agreements based on service requirements; and 8) Updates to other parts of the Service Management System [12].

Construction and Transition activities correspond to the implementation of the service, to verify that the service requirements, service acceptance criteria, customer satisfaction and documented service design are met. Among the activities is to assemble components or services and test them [12]. In the event that the service acceptance criteria are not met, actions are agreed upon by the stakeholders, which may include deferring deployment and correcting known errors. Once the service is deployed, stakeholders are informed of the success or failure of the implementation, and the achievement of the outcomes of the new or modified service is verified.

2.4 Agile IT service design-building phase-workflow in ITIL v4

ITIL v4 [24] can be considered the most known and relevant agile ITSM framework. It was derived from its practical legitimacy gained for its extensive utilization from two decades ago with the previous v2, v3, and v2011 versions. ITIL v4 [24; p. 14] has been re-defined and re-structured as a Service Value System (SVS) “to ensure a flexible, coordinated and integrated system for the effective governance and management of IT-enabled services.” ITIL v4 does not claim to be an SVS for the whole organization but it indicates that with the new business dynamic demands for digital transformations, enhanced customer experiences based on IT, and the proliferation of new practices and technologies such as Agile Paradigm, DevOps, Lean, Cloud Computing, Internet of Things and Machine Learning, most of the business services are IT-based enabled services. Thus, an updated ITSM framework is required.

ITIL v4 keeps the concept of Service Management as “a set of specialized organizational capabilities for enabling value for customers in the form of services” [24, p. 18]. However, the focus on the five-phase IT service lifecycle model (i.e., Service Strategy, Design, Transition, Operation, and Continual Improvement) has been re-structured in the concept of the six-phase service value chain, which is one of the five core components of the new SVS. However, these five IT service lifecycle phases have been implicitly included and updated in the six-phase service value chain. The concept of service is kept as “a means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks” [24, p. 248], and the concept of IT service is simplified to “a service based on the use of information technology” [24, p. 242]. The concept of value which was indirectly defined as how well an IT service helps to achieve the expected customer’s outcomes for using such an IT service now has been explicitly defined as “the perceived benefits, usefulness, and importance of something” [24, p. 20]. In particular, the concept of ITSM is not explicitly defined in ITIL v4.

The five core components of the ITIL v4 SVS are ITIL v4 Service Value Chain (ITIL v4 SVC), ITIL v4 Practices, ITIL v4 Guiding Principles, Governance, and Continual Improvement. The six-phase ITIL v4 SVC defines a flexible and adaptable operational model for creating, delivering, and continually improving IT services. The ITIL v4 Principles aim to guide organizational decision-making and behaviors toward an adequate service management culture to be applied from top to bottom organizational levels. There are eight principles. The ITIL v4 Practices are organizational resources that guide it on what work to do. There are three categories of ITIL v4 Practices (General Management, Service Management, and Technical Management). ITIL v4 Governance refers to the top-level policy and regulation body created to assure the alignment of the IT actions with the IT strategies, policies, and regulations. The ITIL v4 Continual Improvement model is reported as usable and required for all organizational areas from strategic to operational levels. The previous 7-phase model from ITIL v3-v2011 is supported. The four ITIL v4 dimensions represent viewpoints on the ITIL v4 SVS and these are fundamental for achieving effective and efficient service management which delivers IT services and/or IT products with the expected value. These dimensions are Organizations and People, Information and Technology, Partners and Suppliers, and Value Streams and Processes. Important is the consideration of political, economic, social, technological, legal, and environmental factors which by their external nature are out of the control of the ITIL v4 SVS but which must be considered because they constraint and influence the four ITIL v4 dimensions. In the updated ITIL v4 ITSM framework, there are not mandatory IT practices to be performed. The new flexible and adaptable ITIL v4 SVS model defines a generic six-phase SVC (plan, improve, engage, design and transition, obtain/build, and deliver and support). This 6-phase SVC can accommodate flexibly the utilization of the 34 ITIL v4 Practices (14 of General Management, 17 of Service Management, and 3 of Technical Management). These 34 ITIL v4 practices are not restricted to be used in a specific phase of the ITIL v4 SVC. Instead, there is a heat map reported for each practice to show where it is expected to use (but not in mandatory status) such a practice. Consequently, ITIL v4 proposes a flexible, adaptable, and highly customized Service Management model where each organization is responsible to define its Value Streams. Value Streams are “specific combinations of activities and practices, and each one is designed for a particular scenario” [24; p. 83]. A Value Stream starts with customer demand and ends with the delivery of value to such a customer. Value Streams can be organized as disciplined, agile, or hybrid flexible workflows, and it is an organizational decision. Furthermore, some Value Streams, for their criticality level can be designed for a disciplined approach and others with more flexible approaches (i.e., Agile, Lean, DevOps).

ITIL v4 defines the concepts of business architecture, information architecture, and service architecture. The business architecture is a map of the business capabilities and their interrelationships to create value to customers. The information architecture refers to logical and physical data assets of the organization, and their resources for management them. The service architecture exhibits a map of all IT services provided by an organization. Service architectures use the concept of IT service map or model is a high-level view that portrays how the IT service components are linked to compose an IT service and interact to create value to customers. Figure 

ITIL v4 IT service architecture high-level view—service map

Full size image

8 is an example of an IT service map.

Regarding the specific inquiry on how an IT service is designed in ITIL v4, there is not reported a mandatory value stream. Thus, it permits now multiple ways for doing it (i.e., IT service design value streams fixed by a particular organization). ITIL v4 indicates that its SVC can select the utilization of the most suitable ITIL v4 Practices to transform the inputs (i.e., demands) to outputs (i.e., products or services with value). An additional literature on ITIL v4 [53] suggests a value chain and value stream for designing a new IT service. This value chain describes the demand path in six key steps. Figure 

ITIL v4 value chain steps for designing a new IT service

Full size image

9—from ITIL v4 [25]—shows the value chain steps for the creation of a new service [25]; (p. 65). These six steps are: (1) Engage: acknowledge and document the service requirements; (2) Plan: decide whether to invest in the new service; (3) Design and Transition: design and architect the new service to meet customer requirements; (4) Obtain/Build: configure or buy service components; (5) Design and Transition: deploy service components in preparation for launch; and 6) Deliver and Support: Release new service to customers and users.

The input and output for this value chain and value stream are demand and value. This value stream is triggered by a demand for the creation of a new service, which may come from: (1) a service consumer (external or internal), either a customer, a user, or a sponsor; (2) an external stakeholder other than the service consumer, such as a supplier or regulator; (3) a staff member of one of the service provider’s business functions; or (4) members of the organization’s governing body. It is important that the demand considers the desired outcomes and the expected value of the service, and for this a useful technique is to adapt the agile software development template commonly used for defining user stories. As a I < type of user > I want < service functionalities > so that < service benefits > . These six core steps refer as follows.

Step 1—Engage. “Acknowledge and document the service requirements: Any new product or service feature begins with demand recognition and documentation” [25, p. 67]. To gather and evaluate requirements, different business case methods are typically used to gather sufficient information to make a business case. For the business case, high-level information is gathered, from benefits (quantitative and qualitative), costs, risks, operations, support, among others. Main practices used in this step are: Business Analysis, Portfolio Management and Relationship Management. Step 2—Plan. “Decide whether to invest in the new service: In this step it is decided whether to approve the business case, and for this it is necessary to analyze and evaluate the costs, benefits, and risks, so that the organization can carry out the planning” [25]; (p. 68). Main practices used in this step are: Business Analysis, Infrastructure and Platform Management, Portfolio Management, and Problem Management. Step 3—Design and Transition. “Design and architect the new service to meet customer requirements” [25, p. 68]. In this step, the budget for developing the planned IT service has already been authorized to guarantee the request for the new service or changes for new functionalities of a service. In the case of changes for new functionalities, it is necessary to review and modify the design to incorporate the new features. This step elaborates a service design pack including an IT service map and all additional technical information required for developing a minimum viable IT service. Main practices used in this step are: Architecture Management, Availability Management, Capacity and Performance Management, Information Security Management, Service Continuity Management, and Infrastructure and Platform Management. Step 4—Obtain/Build. “Build, configure, or buy service components. Once the service design package is defined, work can begin to procure or build the service components” [25, p. 71]. Main practices used in this step are: Infrastructure and Platform Management, Service Configuration Management, Service Validation and Testing, and Supplier Management. Step 5—Design and Transition. Deploy IT service components and plan IT service release. Main practices used are: Deployment Management, Service Configuration management, and Supplier Management. Step 6—Deliver and Support. Release new service to customers and users. The service implemented receives an early-life support short period of time. Main practices used are: Release Management, Incident Management, and Relationship Management.

2.5 Agile IT service design-building phase-workflow in VeriSM

VeriSM [26, p. 376] is defined as a “value-driven, evolving, responsive, and integrated service management approach” for the entire organization in the digital era, and not only for the IT area. A service management approach is a management approach to deliver value to customers through quality products and services. VeriSM indicates that whereas the ITSM best practices frameworks have provided value to organizations in the last decade, the new digital business era demands a broader IT-based or digital transformation approach for the entire organization, and thus, these ITSM frameworks are insufficient to cope with the business demands in this digital era. VeriSM aims to help organizations on how they can use integrally a mesh of best management practices in a flexible way to deliver the right product or service at the right time to their customers.

VeriSM is documented with a service management operating model composed of Consumers, Governance, Service Management Principles, and the Management Mesh. The implementation of VeriSM approach enables organizations to define governance requirements, service management principles, a management mesh of best practices, and the service or product stages from their definition, production, responding, and provision.

Customers provide the product or service requirements, pay, receive and give feedback for the products or services. Governance provides the background system to direct and regulate the activities of an organization, and Management provides the foreground system which manages the activities of an organization into the boundaries and regulations fixed by Governance. Governance consists of three main activities (evaluate, direct, and monitor). Evaluate refers to compare the overall current organizational status vs the future forecasted or planned ones. Direct refers to create organizational principles, policies, and strategies. Monitor refers to assure that policies comply as they were planned, and the strategic performance reaches the expected one. Service Management Principles are statements that define how the organization wants to perform and what is valued. Service Management Principles, thus, help to define the specific best practices to include in the Management Mesh. Service Management Principles address usually assets/resources utilization, change, continuity, financial, knowledge, measurement and reporting, performance, quality, regulations, risk, and security issues.

Management Mesh refers to the integral and flexible fabric composed of organizational resources, management practices, current and emergent technologies, and environmental conditions. This Management Mesh enables a flexible and agile management service approach in organizations to define, produce, provide and respond to their products and services. The definition of a particular Management Mesh happens after the definition of Governance strategies and policies, and Service Management Principles. In particular, the environmental conditions in the Management Mesh include the called service stabilizers (processes, tools, and measurements). This Management Mesh lately defines four functional areas/stages for developing and providing the products and services of the organization. These are Define, Produce, Provide and Respond. There are 4, 3, 3, and 2 high-level activities respectively in the four stages. The four activities of the Define stage are consumer need, required outcome, solution, and service pro forma. The 3 activities of the Produce stage are build, test, and implement and validate. The three activities of Provide are protect, measure and maintain, and improve. The two activities of Respond stage are record and manage.

VeriSM uses the concept of service pro forma to represent the IT service architecture. A service pro forma reports the service components—software, hardware, network, data, facilities, performance, testing and training requirements, and communication and implementation plans. Figure 

VeriSM IT service pro forma

Full size image

10 exhibits an interpreted IT service pro forma of example.

The IT service design issues in VeriSM corresponds to the Define stage. Its objective is providing the activities and outcomes (artifacts) related to the service or product design in conformance with the Governance policies and Service Management Principles to meet the performance, security, risk and quality requirements. The 4 high-level activities are consumer need, required outcome, solution, and service pro forma. In consumer need, a demand for a product or service is presented and authorized or rejected. In the required outcome, the service or product requirements of diverse types (functional and non-functional ones) are gathered. In solution, a design plan is elaborated which includes service attributes (capacity, availability, continuity, security), risk issues, testing issues, training issues, implementation plan, people involved, supply chain, facilities, infrastructure and technology, metrics, knowledge for ongoing and improvement activities, and support processes and tools for delivering the service or product. Finally, in service pro forma, the details for the service or product delivering/production are generated. In this Define stage, the implicit outcomes (artifacts) to generate are service/product proposal, service/product requirements, service/product solution, and service/product pro forma.

2.6 Agile IT service design-building phase-workflow in ISO/IEC 29110-4-3:2018 standard complemented with ISO/IEC TR 29110-5-3:2018

The ISO/IEC 29110-4-3:2018 standard [27] provides the specification for the Service Delivery profile of the ISO/IEC 29110 family of standards. The ISO/IEC 29,110 set targets Very Small Entities (VSEs), defined as organizations, or departments or teams from 1 up to 25 people. The ISO/IEC 29110 family of standards and technical reports address software engineering, system engineering, and service delivering processes. A profile of application refers to a set of defining characteristics for a specific target group. A complementary technical report is the ISO/IEC 29110-5-3:2018 [52] that provides guidelines to manage services delivered to customers in VSEs.

The ISO/IEC 29,110–4-3:2018 standard defines the requirements for four processes, which contain eleven activities, forty tasks, twenty-one work products, and eight roles altogether. The four processes are Governance (GO), Service Control (SC), Service Relationships (SR), and Service Incident (SI). The first Governance process pursues to establish a system to direct and control service delivery activities efficiently and effectively. The second Service Control process aims to support and control the design, building, and transition of new or changed services. The third Service Relationships process assures that documented agreements for services, valid communications, and valuable feedback maintain adequate relationships between the service provider and its customers and providers. The fourth Service Incident process aims to prevent service disruptions and restore them in the event of a service disruption.

Four Governance objectives include GO.O1 define the scope of the service delivery activities and assigning authority; GO.O2 implementing a service delivery policy, objectives, and plan(s); GO.O3 establishing a management structure; and GO.O4 report on and improving the services provided to customers. Four Governance activities are linked to the objectives, which include GO.A1 define the scope of activity and required roles; GO.A2 define and implementing governance structures; GO.A3 manage resources including documentation; and GO.A4 complete reporting and improvement activities. Eight Governance work products are WP.01 business goals and objectives; WP.04 customer experience approach; WP.05 data and document management procedure; WP.06 Feedback log; WP.07 improvement report; WP.08 list of assigned roles; WP.14 service delivery policy, objectives, and plan(s); and WP.15 service delivery scope. Two Service Control objectives include CO.O1 control and manage change to services and subsequent deployments and CO.O2 secure and mitigate risks to data and information assets. Three Service Control activities include CO.A1 manage change to services; CO.A2 evaluate and build the service change; and CO.A3 test and deploy approved service change. Eight Service Control work products are WP.02 configuration record; WP.09 secure component procedure; WP.11 service change request; WP.12 Service change schedule; WP.13 Service change—built; WP.16 service design; WP.17 service design, build, test, and deployment procedure(s); and WP.20 service test report. Two Service Relationships objectives include RE.O1 defines clear, mutually beneficial agreements between the VSE, its customers, and suppliers, and RE.O2 completes regular reviews with stakeholders to ensure current and future needs are met. Two Service Relationships activities include RE.A1 creating and/or maintaining a suitable service catalog and RE.A2 Establishing and managing agreements with customers and suppliers. Four Service Relationships work products include WP.03 customer agreement; WP.10 service catalog; WP.19 service performance report; and WP.21 supplier agreement. Two Service Incident objectives include IN.O1 prevents incidents to ensure services are available and delivered as agreed and IN.O2 manages incidents, including communication, to maximize the service experience. Two Service Incident activities are IN.A1 prevent incidents and IN.A2 manage incidents. One Service Incident work product is WP.18 service incident record.

Details of the forty tasks are not reported here due to space limitations. However, it is important to note that detailed information on the forty tasks is reported in the complementary technical report ISO/IEC 29,110–5-3:2018 [56]. Besides, this technical report includes descriptive details for each one of the twenty-one work products. Finally, the eight suggested roles in this ISO/IEC 29110-4-3 standard are Control Manager, Customer, Incident Manager, Management of the VSE, Practitioner, Relationship Manager, Service Manager, and Supplier. Several roles can be played by the same people, but these roles cannot be combined into a single role.

In the ISO/IEC 29110-4-3 the IT service architecture corresponds to a generic diagram of the service solution(s) which includes the components required functionality, the IT infrastructure that supports the components, the processes to support and manage the solution, the associated measures (internal performance or customer agreed measures), and the supply chain interfaces. Figure 

ISO/IEC 29110-4-3 vital business IT services architecture

Full size image

Fig. 11 represents an example of an IT service architecture in the ISO/IEC 29110-4-3.

In the ISO/IEC 29110-4-3 standard, the design of an IT service corresponds to the category of Service Control. The three activities are: CO.1 manage change to services; CO.2 evaluate and build the service change; CO.3 test and deploy approved service change; and RE.2 establish and manage agreements with customers and suppliers. CO.1 activity includes five tasks: CO.1.1 define type and method of change; CO.1.2 define the service design, build, test & deployment procedures; CO.1.3 approve the service design, build, test and deployment procedures; CO.1.4 identify service components; and CO.1.5 define and approve appropriate procedures to store and protect service components. CO.2 activity has four tasks: CO.2.1 evaluate service change request; CO.2.2 update the service change schedule to reflect proposed deployment date; CO.2.3 use appropriate design activities to fulfil the change requirements; and CO.2.4 build the change. CO.3 has five tasks: CO.3.1 perform documented tests; CO.3.2 review test report based on agreed customer functionality and obtain approval to deploy the service change; CO.3.3 review service change schedule ensuring the availability of resources to deploy the change; CO.3.4 deploy the approved service change, as planned and documented; and CO.3.5 review the results of the deployment and manage improvement. RE.2 activity has two tasks: RE.2.1 draft agreements with customers and/or suppliers to ensure understanding on delivery parameters and performance measures; and RE.2.2 approve agreement(s).

There are six main work products used and generated in the IT service design process. These are WP.01 business goals and objectives (GO); WP.03 Customer agreement (RE); WP.04 Customer experience approach (GO); WP.16 service design (CO); WP.17 service design, build, test & deployment procedure(s) (CO); and WP.20 service test report (CO). WP.1 (GO) contains business statements that guide how that specific organization operates and makes decisions. WP.03 (RE) contains: Unique identifier; A documented form of approval (e.g., email, signature, etc.); Scope of service(s) to be provided; Key dates (start, review, end); Defined owner of the agreement for the VSE and customer. WP.04 (GO) registers and manages a log for all comments (compliments, complaints, general comments) from customers. WP.16 (GO) contains: Unique identifier; Date of issue and status; Approval authority; Identification of tools, methods and techniques; Budgets and cost estimates; Resources and their allocation, including human resources, technical resources (infrastructure) and tools; Responsibilities and authority, including the senior responsible owner and immediate process or service owner; Risks and risk identification, assessment and mitigation activities; Quality assurance and performance measures. WP.17 (GO) contains: Creating a service change request; Updating the service change schedule; Defining and managing emergency service changes; Removal of service(s) or service component(s)). WP.20 (CO) contains: Unique identifier; Summary of test results; Testing levels and types of tests; Measurement system and interpretation of results; Errors and their resolution; Test information (who performed, when data was collected, who interpreted, who validated.

Appendix 3. AHP pairwise comparison matrices for the rigorous IT service design-building index

See Tables [17, 18, 19, 20]

Appendix 4. AHP pairwise comparison matrices for the agile IT service design-building index

See Tables [21–24]

Appendix 5. AHP input matrices for the rigorous IT service design-building index

See Tables [25–27]

Appendix 6. AHP input matrices for the agile IT service design-building index

See Tables [28–30]

Springer Nature or its licensor (e.g. a society or other partner) holds exclusive rights to this article under a publishing agreement with the author(s) or other rightsholder(s); author self-archiving of the accepted manuscript version of this article is solely governed by the terms of such publishing agreement and applicable law.

Reprints and permissions