1 Introduction

According to Balaji and Brown (2005), provider management in information technology (IT) outsourcing projects comprises the client’s activities to plan, control, coordinate, and maintain provider relationships. In information systems (IS) research, the management of IT outsourcing relationships is considered to be an essential factor that can make or break the outsourcing project (Lacity and Willcocks 2003; Ruzzier et al. 2008; Urbach and Würz 2012). However, provider management is always challenged by new management approaches such as agile project management (Wiedemann and Wiesche 2018) or new technological concepts. One of these seminal technological concepts is cloud computing. Over the past decades, cloud computing has emerged and it continues to change the fundamental characteristics of IT service provisioning (Buyya et al. 2009; Xiao and Hedman 2019; Keller et al. 2019). Cloud computing is a form of IT provisioning with which pooled IT resources are offered to clients, the users of cloud services, in a flexible and scalable manner without requiring a long-term capital commitment or IT-specific expertise (Armbrust et al. 2010; Marston et al. 2011; Mell and Grance 2011). Due to these characteristics, cloud services can both reduce IT costs as well as open up new business opportunities (Marston et al. 2011; Etro 2009). IT managers have quickly recognized the opportunities at hand, and thus, cloud computing adoption increased (Xiao and Hedman 2019; Fahmideh et al. 2018).

Following the broadly accepted definition of the National Institute of Standards and Technology, cloud computing consists of three different service models (Software as a Service—SaaS, Platform as a Service—PaaS, and Infrastructure as a Service—IaaS) and four deployment models (private, community, public, and hybrid) (Mell and Grance 2011). However, the general understanding of cloud services with the aforementioned characteristics mostly focuses on public cloud services for all three service models. In such scenarios, provider management becomes especially relevant owing to the external hosting of infrastructure and systems by the cloud service provider (CSP) (Mell and Grance 2011). Thus, public cloud services may require configuration and a suitable integration in organizations’ IT landscape. In the following, we refer to public cloud services unless otherwise stated.

The transition from traditional IT outsourcing to the cloud sourcing era has radically changed client–provider relationships (Willcocks et al. 2012; Huntgeburth 2015). The associated shift from IT-as-a-product to IT-as-a-service places enterprise cloud clients in a constant dependency on the availability and the security mechanisms of the CSP (Keller and König 2014). Clients hand over confidential data as well as the control over critical IT infrastructure and applications to the Internet (Chaput and Ringwood 2010; Ali et al. 2015; Huntgeburth 2015), and the abstraction provided by cloud computing leads to a perceived lack of transparency (Venters and Whitley 2012) and a loss of control (Jansen 2011; Jansen and Grance 2011). Furthermore, enterprise cloud clients must rethink the role of the internal IT department (Malladi and Krishnan 2012; Willcocks et al. 2012; Prasad et al. 2014) as well as the characteristics of the outsourcing relationship that defines how clients and cloud providers interact in the era of cloud sourcing (Hon et al. 2012; Schlagwein and Thorogood 2014). In standardized public cloud scenarios, cloud computing’s pay-as-you-go model and its scalability are convenient for clients and promise substantial cost savings as well as the transfer of responsibilities to the provider. Cloud services allow organizations to access high-end IT services without requiring high initial investment (Marston et al. 2011) and to “respond quickly to changing capacity requirements” (Repschlaeger et al. 2012, p. 6). More specialized services (Hoefer and Karagiannis 2010) in the context of SaaS lead to fine-grained providers for specialized solutions (Wang et al. 2014). However, an unmanaged relationship likely leads to a dependency on the CSP, which can have several downsides, e.g., vendor lock-in (cf. Opara-Martins et al. 2014). Furthermore, without appropriate provider management, the lack of transparency in cloud offerings may increase and, thus, reinforce risks in client–provider relationships (Keller and König 2014; Keller 2019). Consequently, the importance of managing business relationships with CSPs has increased to become a critical success factor for clients.

Although some approaches for specific aspects of cloud provider management already exist (Armbrust et al. 2010; Marston et al. 2011; Subashini and Kavitha 2011; Garrison et al. 2012; Vithayathil 2018), research still lacks a holistic framework that addresses all phases from the pre-contract to the post-contract stage. Furthermore, existing approaches do not consider the specific realities of the client–provider relationship in practice. To address the current issues and to add to the scientific discourse on managing relationships between providers and clients, we seek to answer the following research question:

What are the relevant processes to manage cloud computing providers and what contingencies influence the client–provider relationship?

To answer this research question, we reviewed the literature on existing challenges in the client–provider relationship and existing approaches to cloud provider management. Furthermore, we enriched the literature review with insights from interviews with domain experts. We synthesized our findings in a process framework for managing cloud computing providers. In this context, we exclude preceding strategic questions during the outsourcing process (e.g., decisions on make-or-buy), but focus on the business relationship and all client–provider interactions instead. Since provider management depends on companies’ realities, we identified contingency factors during the research process that impact the proposed management processes. Our cloud management framework aims at researchers and practitioners who seek to better understand client–provider interactions in cloud computing from a client perspective.

The remainder of this paper is structured as follows: In Sect. 2, we describe the theoretical background of client–provider relationships in cloud computing before we illustrate our research approach in Sect. 3. Subsequently, we introduce the ten processes of our cloud management framework in Sect. 4. In Sect. 5, we elucidate the three contingency factors and illustrate potential adjustments for the ten cloud management processes. Finally, in Sect. 6, we discuss, conclude, and reflect upon our findings.

2 Theoretical background on client–provider relationships

Managers may either concentrate on core competencies or strategic outsourcing as two basic principles to “leverage their companies’ skills and resources well beyond levels available with other strategies” (Quinn and Hilmer 1994, p. 43). In this paper, we focus on outsourcing, which has, for instance, a long tradition in supply chain networks, where companies utilize their business network to seek competitive advantage (Hallikas et al. 2002).

Similarly, IT outsourcing is a well-established and well-described phenomenon (cf. the survey and analysis of Dibbern et al. 2004). Early publications already dealt with the make-or-buy decision (Buchowicz 1991) or the phenomenon itself (Gupta and Gupta 1992; Lacity and Hirschheim 1995; Willcocks and Kern 1998). Thus, the literature has frequently addressed the question if companies should or should not outsource hardware, software, or both (Lee et al. 2003). However, research has often debated on IT outsourcing’s effectiveness, since companies face a trade-off between flexibility needs and control needs (Quinn and Hilmer 1994). Furthermore, the emergence of application service providers catalyzes this trade-off (Dibbern et al. 2004).

A critical influencing factor in balancing those needs is the client–provider relationship. From a client perspective, the search process for the right partner initiates this relationship (Wadhwa and Ravindran 2007). Having found the right provider, the literature identified the steering of IT service providers as a crucial success factor in IT outsourcing (Urbach and Würz 2012). Prior research has already carved out relevant process steps of steering processes: after the initial contract negotiation and the subsequent service transition, steering also consists of the cultivation of the client–provider relationship, the improvement of the underlying service, and usually ends with the termination of the IT outsourcing contract (cf. Barthelemy 2001; Urbach and Würz 2012). In contrast to this rather organizational perspective, service lifecycle management provides a more technical perspective on the client–provider relationship in IT outsourcing (Fischbach et al. 2013). While most of the literature on relationship management takes on a provider perspective (cf. Kamprath and Röglinger 2010; Lambert 2009), relationship management issues from a client perspective are also manifold. Research streams in supply chain management, for instance, go way beyond the mere steering of a provider, but rather deal with the integration of production chains to co-create value (cf. Galvagno and Dalli 2014; Lambert and Schwieterman 2012).

In contrast to these research domains, cloud computing’s non-storable services (Keller 2016), its pay-as-you-go model, and its scalability induce more standardized products (Armbrust et al. 2010). Thus, cloud computing changes IT departments’ interaction with their providers in comparison to traditional IT products (Willcocks et al. 2012; Huntgeburth 2015). The transformation to cloud computing fosters multi-sourcing strategies as well as the consumption of distinct, specialized services (Keller 2019). Consequently, the complex interaction between multiple cloud services may lead to a perceived lack of transparency (Venters and Whitley 2012) and loss of control (Jansen 2011). While companies can store products in warehouses and traditional software permanently runs after its installation, clients that consume cloud services are in a constant dependency on the availability and security mechanisms of their CSP (Keller and König 2014).

Coping with cloud computing’s specifics for client–provider relationships, governance frameworks in academic literature seek to provide new standards. Most frameworks focus on assessing and handling existing risks associated with cloud computing usage, and address common data security and trust issues (Ahmad and Janczewski 2011; Ko et al. 2011; Alruwaili and Gulliver 2014; Martens and Teuteberg 2011; Zhang et al. 2010). Other studies refer to performance monitoring (Alhamad et al. 2010; Jeon et al. 2014) or the management of cloud computing in application scenarios (Huang et al. 2010). Furthermore, Loebbecke et al. (2012) provide a guided approach to identifying cloud-ready IT services.

However, despite the abundant literature on cloud governance, only a few papers focus on the client–provider relationship from acquisition to its termination. Xiao and Hedman (2019), for instance, describe the client–provider relationship from a provider perspective. They illustrate how a provider changed its business model and therewith its internal processes and mindset to provide SaaS. Furthermore, they illustrate how the provider must integrate its clients in the change process. Grati et al. (2015) consider the lifecycle of a service from a technical perspective and provide a meta-model for provider management entities that contain service-level agreements (SLAs), billing, and monitoring.

Other authors focus on the client perspective. Joha and Janssen (2012), for instance, identify required IT governance capabilities to adopt cloud computing in public sector organizations. They identify capabilities in the areas of business, technical, supply, and governance and guide practitioners on how to overcome existing challenges. Digging deeper into the promises of cloud computing, Winkler et al. (2014) analyze the so-called mantras of cloud services (i.e., financial benefits, technological implications, and organizational implications) and describe the trade-off for cloud clients. From an in-depth analysis of a single case, they derive nine lessons learned to achieve cloud payoffs. They recommend multi-sourcing strategies as well as the involvement of internal IT staff. They also advocate an in-depth analysis of providers as well as contract negotiation. Regarding the functional requirements, they suggest partnering with the provider as well as extending the SaaS customization options using PaaS offerings. Finally, they emphasize the need for compliance with existing regulations. Focusing on the suggested multi-sourcing strategies, Schlagwein and Thorogood (2014) describe how to integrate several cloud providers to dynamically switch between their offerings. They identify the necessity of enforcing technical standards across providers and of being an early-adopter of industry standards as well as flexible contracts. Furthermore, they argue for retaining internal capabilities to “become a competent IT broker able to integrate external and internal IT resources and to design state-of-the-art overall IT solutions” (Schlagwein et al. 2014, p. 210). Finally, Schneider and Sunyaev (2015) focus on how to engage service providers in cloud sourcing relationships from the client perspective. Therefore, they build a cloud service life cycle framework in which they describe the relevant phases of cloud service provisioning as well as the points of interaction between clients and providers: requirements determination, acquisition, integration, contract fulfillment, development, and termination. However, similar to Xiao and Hedman (2019), Schneider and Sunyaev (2015) mostly describe their insights from a provider perspective. Aside from those research papers, practitioner guides such as COBIT 5 or ITIL 3 offer managerial recommendations (Information Technology Service Forum 2012; COBIT 2014), but are mostly neither theoretically nor empirically grounded (Urbach and Würz 2012).

3 Research method

Our research process consisted of two major components. First, we conducted a literature review to identify and synthesize the relevant work on client–provider relationships in cloud computing. Based on the findings from the literature, we drafted an initial cloud management framework. Second, we conducted semi-structured interviews with sixteen experts in the field to validate the initial framework. Iteratively enhancing the framework, the interviewees’ feedback helped us to extend, substantiate, and corroborate our findings. In the following, we provide further details on the two components of our research process.

3.1 Literature review

For our literature review, we followed the guidelines of Vom Brocke et al. (2015) and Webster and Watson (2002). As Vom Brocke et al. (2015) suggest, our research question guided the research process in an iterative, yet systematic manner. In a preliminary literature search, we gained an overview of existing literature to structure the subsequent steps. While our preliminary search focused on identifying holistic models for the client–provider relationship, our structured literature search specifically sought to gain a comprehensive overview of the existing literature.

We collected literature from six major scientific databases (ACM Digital Library, AIS electronic library, EBSCOhost Business Source Premier, IEEE Xplore, ProQuest, ScienceDirect) to allow for broad coverage of research domains (Vom Brocke et al. 2015). Drawing on the insights from our preliminary literature search, we defined ten search strings that concatenate cloud computing with different perspectives (client, provider, management, and sourcing) and our focus on client–provider interaction or the client–provider relationship (see Table 1).

Table 1 Search strings for the structured literature review
Full size table

Applying the search strings with no other restrictions resulted in 1804 search results. After removing duplicates across search strings and databases, we began to verify the remaining 1165 search results. Next, we excluded false-positives (e.g., table of contents and front covers) and screened the publications’ titles according to predefined inclusion and exclusion criteria that we had discussed among the authors. For instance, we excluded publications from other domains with no immediate focus on the cloud computing concept (e.g., biology) or publications that clearly focused on non-management aspects (e.g., technical papers). After this step, 225 potentially relevant search results remained. Finally, we checked the publications’ abstracts and—where the abstract did not provide a clear indication—their full texts to derive our final literature sample of 37 publications (see Appendix 1). Thereby, we again applied our inclusion and exclusion criteria in accordance with our research question. Following Webster and Watson (2002), we synthesized the findings from the literature review in a concept matrix (see Appendix 1).

The findings from our literature review corroborated our research question and the underlying motivation. The majority of the publications adopted a provider focus and addressed selected topics such as SLA design, pricing strategies, or trust and security issues. In contrast, barely, any papers provided a comprehensive view of the cloud management lifecycle or prescriptive insights on managing the client–provider relationship. Thus, while the structured literature review helped us to compile an initial collection of cloud management processes (see Appendix 2), we saw the need to engage in our own data collection to gain in-depth insights from interviews. Yet, we iteratively revisited our literature review results throughout the subsequent data collection to consider extant work and to update the concept matrix. Furthermore, we performed a backward and forward search (Vom Brocke et al. 2015) to back the findings from our interview study with literature.

3.2 Interview study

To further explore the relationship between providers and clients on top of our literature review, we opted for a qualitative-empirical research method to validate our preliminary results and to gain a deeper understanding of the management processes (Bettis et al. 2015; Goldkuhl 2012). Based on interviewees’ opinions, we iteratively incorporated corroborating and constructive feedback into our preliminary framework. While we used the initial framework derived from the literature in the first interview, we revised the cloud management framework after each interview round. This enabled us to incorporate new insights quickly and gain feedback on the changes in subsequent interviews. Since the number of suggestions for improvement decreased significantly throughout the interviews and no or only minor suggestions for improvement resulted from the last interviews, we can assume saturation.

Besides further insights and validation of the cloud management framework itself, the interviews also revealed indications for contingencies related to the management processes. During data analysis, we compared the interview findings across the different cases and identified relevant contingency factors that influence the processes’ reasonability and configuration in our cloud management framework. Thus, we specifically sought to unravel those contingencies in later interviews as an emerging theme in our research process. In joint discussions in the research team and by revisiting earlier interviews as well as the literature, we conceptualized the contingency factors and their potential implications for our cloud management framework. While the contingencies were brought up during the frameworks’ validation and, thus, require further substantiation, we see them as a valuable contribution to better understand the different manifestations of our management processes in practice.

In line with the guidelines of Myers and Newman (2007) and Schultze and Avital (2011), we conducted 12 semi-structured interviews with 16 experts from the area of cloud sourcing to gain comprehensive practitioner insights. To increase the validity of our results, we sought to validate the framework from different angles. We considered both interviewees from the client’s point of view and the CSP perspective and cloud management consultants. All interviewees were well experienced within the fields of IT service provisioning and cloud projects for at least 2 and up to 25 years. The interviews were audio-recorded and then transcribed for further analysis and reference. The interviews lasted between 45 min and 2 h. We conducted three interviews as a group interview of at least two employees from the same organization, i.e., Interviewees [Va–c], Interviewees [VIIIa–b], and Interviewees [Xa–b]. Table 2 depicts an overview and the order of data collection, as well as additional information on the interviewed experts.

Table 2 Overview of the interviewees and their background
Full size table

For data analysis, we used qualitative content analysis techniques (Mayring 2014) and analyzed our data in MAXQDA. Thereby, the first two authors systematically analyzed the interview transcription word-by-word using a categorical coding scheme which we initially developed based on the theory available (Mayring 2014). Thus, our scheme comprised the initial processes in our framework as the main categories. During data analysis, we extended our theoretically derived coding scheme whenever new topics emerged from our data. Here, we also started to identify our contingency factors. Thus, we created new codes and allocated them to a suitable category. All authors thoroughly reviewed our codes and categories in the middle and at the end of data analysis to summarize codes and create sub-categories where the coding scheme was too generic. Thereby, we ensured the clarity and precision of our coding scheme.

4 Developing a cloud management framework

In this section, we illustrate our cloud management framework. For reasons of simplification, the following subsections and Fig. 1 present the final cloud management process framework, which is guided by the literature and our interview findings (see Appendix 2 for the initial cloud management framework). The final framework comprises ten processes to manage CSPs from the client perspective.

Fig. 1
figure 1

Final cloud management framework

Full size image

In the following subsections, we describe each of the ten cloud management processes in detail and provide insights from the empirical validation. To increase the intelligibility and the applicability of the framework, we used the established approach in IS research of arranging processes in a life cycle view which provides a chronological sequence of the management processes (Heckman 1999; Schneider and Sunyaev 2014). Thereby, we divided the life cycle into three phases: (1) pre-contract, (2) contract, and (3) post-contract (Chou and Chou 2009).

We distinguish eight primary and two secondary cloud management processes. The primary processes comprise distinct management areas during the cloud service provisioning. Thus, the primary processes describe either clients’ direct interactions with the CSP or the activities to prepare, monitor, and steer CSP’s actions. In contrast, secondary processes are support processes in terms of relational and risk management aspects that clients must consider in every primary process. Furthermore, they are not time-limited but require continuous governance. In this context, the life cycle approach structures our results for better comprehensibility and increases the feasibility of the framework. The interview findings show that our interviewees positively acknowledge the life cycle arrangement (e.g., “I think it's perfect to build the whole thing based on the life cycle, which makes the model very clear. […] The structure of the life cycle increases the comprehensibility enormously”, Interviewee [IIa]; “This is what a regular SaaS life cycle look like”, Interviewee [Xa]).

4.1 Service and provider selection

Clients should first conduct internal requirements engineering activities (Zardari and Bahsoon 2011; Mouratidis et al. 2013), resulting, among others, in the decision on which services should be selected for cloud sourcing. Loebbecke et al. (2012) identify that service selection goes hand in hand with provider selection. Clients must “identify IT services that are likely cloud-ready ahead of vendor sales pitches” (Loebbecke et al. 2012, p. 20), and involve various internal and external stakeholders such as management, employees, technology, and service providers. Clients evaluate offerings and select the CSP that best satisfies their requirements based on their specific characteristics. The provider selection itself might result in one CSP or a shortlist of suitable CSPs with whom the client will engage in negotiations. CSP selection is a crucial cloud provider management process to increase trust and, therefore, highly influences the success of the subsequent client–provider relationship (Liu et al. 2016; Lacity and Reynolds 2014). In this process, the development and application of the appropriate evaluation criteria are essential (Zardari and Bahsoon 2011; Low and Chen 2012; Repschlaeger et al. 2012). This process is also highlighted in the interviews. Interviewee [Xa] states that the “…first thing is the solution that you want and then you check which provider can bring that solution.” Initially, this process only comprised provider selection, but based on the interviewees’ comments (e.g., [Xa]), we relabeled it to service and provider selection. This expresses the necessity to find a suitable match of service and provider characteristics for the client’s needs. Furthermore, client companies need to ensure that CSPs also meet industry-specific regulatory requirements. “Contracts in the financial industry are always part of provider selection. […] For example, the contract determines which rights you need to do an audit. This clause is one of the main factors for the selection of a provider [in the financial industry]”, Interviewee [IX].

4.2 Contract negotiation

The sourcing decision to use cloud services strongly influences the contractual foundation of the sourcing contract as well as its processes (Gold 2015; Gilbert 2010; Trappler 2010). Here, commodity CSPs challenge the traditional way of lengthy contract negotiations by offering non-negotiable and standardized contracts that might not reflect all client requirements (Hon et al. 2012; Pearson and Benameur 2010). However, Winkler et al. (2014), as well as Schlagwein et al. (2014), describe that large organizations also have room for negotiations. Furthermore, cloud contracts should define liabilities and penalties in the case of service outages and contract termination (Hon et al. 2012; Calloway 2012). Our interview findings also emphasize such issues. For example, Interviewee [VI] highlights industry-specific compliance aspects that need to be addressed in the contract negotiation. Especially, topics like “Where is data stored; do I have access to my data; do I also have physical access; do I have the possibility to interfere with my provider; or if my provider has a subcontractor, can I also interfere with them, if something does not work, am I still able to act? […] There need to be contractual regulations, so-called ‘instructions’, with which I have the right to take actions against my provider”, Interviewee [VI]. Moreover, Interviewees [Vb] and [Xa] emphasize the importance of being clear right from the contract negotiations what will happen with the transferred data and how the data are accessible after termination.

4.3 Contract management

The fast deployment and the pay-as-you-go model of cloud service provisioning shift the cost structure into operating expenditure instead of capital expenditure at the beginning of IT outsourcing projects (Weinhardt et al. 2009; Buyya et al. 2009). In comparison to traditional IT management, organizations can perform financial performance management in a much finer granularity that allows the breakdown of resource usage and costs to an individual use or a cloud application level (Bond 2015). Furthermore, organizations must monitor compliance and data security due to the transfer of data and control to the CSP (Kerr and Teng 2012; Kaufman 2009; Wang et al. 2010). In case of unforeseen issues (e.g., regulatory changes and unexpectedly high demand), companies need to renegotiate the existing contract and potentially adapt it. The interview findings show that compliance aspects are decisive for practitioners (Interviewees [VI], [IX], and [Xa]). Therefore, the contract management also needs a constant evaluation of changes in compliance and renegotiation if required.

4.4 Service transformation

The transformation from internal IT to cloud services is critical, since the fit of cloud services to the client’s IT architecture and business processes is not guaranteed (Goyal 2010; Govindarajan and Lakshmanan 2010; Bannerman 2010). Thus, service transformation requires careful preparation with a focus on the adaptation of internal service provisioning, management processes, and data consistency. On-premise deployment approaches are usually not appropriate for cloud services and thus make cloud-specific deployment techniques necessary, especially concerning the automated and rapid provisioning of services (Bond 2015; Li et al. 2012). Moreover, clients often use various cloud services from different sources—even within one business process—which increase the complexity for process owners and end-users (Demchenko et al. 2013; Bond 2015; Böhm et al. 2011). This leads to a demand for transparent multi-cloud provider management to prevent inefficiencies and security risks (Paraiso et al. 2012; Böhm et al. 2011; Schlagwein et al. 2014), as well as platforms which enable the aggregation and resource allocation across all cloud services within the organization (Tordsson et al. 2012; Nair et al. 2010). Service transformation includes the management of multiple CSPs, the transformation to automated service provisioning, as well as customization of outsourced services. Thus, service transformation must feature three capabilities: (1) service aggregation must enable the provision of data across multiple CSPs; (2) service arbitrage consists of all activities involved in choosing the best CSP under contract for each workload; and (3) intermediation involves the distribution and control of service, data consistency, and workloads across multiple CSPs (Bond 2015; Nair et al. 2010; Kandpal 2013). Interviewee [IIa] highlights the importance of data consistency not only in the service transformation itself but also in the preparation before the actual transformation starts. Furthermore, Interviewee [IIa] also sees consistent user interfaces as a challenge that must be addressed in the service transformation. “In the area of service transition, a lot of consulting effort is necessary, which does not work with every CSP. However, many large system integrators such as SAP, IBM, etc. close this gap”, Interviewee [IV].

4.5 Organizational transformation

In cloud sourcing, technological complexity can be hidden from the client through abstraction, which makes the management of IT infrastructure and applications less relevant to the internal IT department (Gong et al. 2010). Traditional centralized procedures in which IT, finance, and functional departments are engaged in the procurement process hinder the flexibility of cloud sourcing (Bond 2015; Jede and Teuteberg 2015). Thus, IT departments require an organizational transformation in terms of restructuring organizational roles and the redefinition of the corresponding internally required capabilities (Garrison et al. 2012; Zhang et al. 2010). For example, a major focus to increase cloud adoption is aligning business requirements and IT provisioning through the cloud (Joha and Janssen 2012; Prasad et al. 2014). Like service transformation, clients must carefully plan their activities to avoid organizational issues. A critical challenge for organizational transformation is getting all relevant stakeholders on board and acquiring the right set of in-house IT capabilities to exploit the value of cloud services, e.g., through application integration skills (Lacity and Reynolds 2014). As the demand for cloud services often originates in non-IT departments, close collaboration is required. Cloud services’ easy accessibility can lead to shadow IT, the unregulated and uncontrolled use of client-external cloud resources (Silic and Back 2014). Aside from data security and compliance risks, shadow IT can also lead to overall architecture inefficiencies and high costs (Silic and Back 2014). “Choosing a cloud service provider means changing the internal processes on the client side. Ideally, the business functions do not realize the change, but sometimes they do, so that the business function also needs a certain transition. And of course, there are also organizational changes in the IT organization. In extreme cases, cloud sourcing can mean that some employees are no longer needed”, Interviewee [IV]. Therefore, Interviewee [IV] proposes conducting change management.

4.6 Demand management

Since clients can easily access cloud services via web interfaces, a coordinated management approach that manages the internal demand is necessary (Bond 2015). Demand management deals with the service ordering process and is necessary for the management of both commodity and specialized services. For micro-transactions and the ordering of individual services, the ordering should be automated, and manual processes should be reduced (Bond 2015). However, order management must also guarantee that service ordering stays within the internal and regulatory policies. Thus, appropriate order management requires flexible authorization concepts that guarantee both flexibility and controllability, e.g., pre-approval for ordering and funding pools (Mell and Grance 2011). In addition to managed ordering, IT departments should govern the automated scaling of cloud resources, because unexpectedly high variable costs might arise (Vaquero et al. 2011). To cover these issues and in contrast to our initial literature-based conceptualization of the cloud management framework, Interviewee [I] recommends “my professional experience clearly shows that demand management […] start very far ahead, right from the start of contract”, Interviewee [I]. Furthermore, Interviewee [VIIIa] approaches their initial demands based on a blueprint approach to best know their needs. Thus, client companies should know their demands upfront to better estimate their costs.

4.7 Performance management

As technical and economical provider performance in IT outsourcing projects is fundamental (McFarlan and Nolan 1995; Kern and Willcocks 2000), the development of a structured approach, including client-specific key performance indicators as well as SLAs, to link business impacts to cloud utilization in the context of benefits management is imperative. Furthermore, companies must monitor their confidential data (Kerschbaum 2011; Grati et al. 2015). Performance management needs to collect, transfer, and analyze data from CSPs, without impairing the ongoing service operation. Thereby, it copes with dynamic changes of monitored entities and facilitates monitoring throughout the upsizing or downsizing of cloud resources (Aceto et al. 2013; Bond 2015). Clients must take a holistic view of services, especially in the case of multi-sourcing (Schlagwein et al. 2014). Furthermore, companies can evaluate what utilization benefits are achieved through cloud sourcing (Greenwell et al. 2014; Aljabre 2012). Based on our interviews, we identify that performance management is crucial but also demanding. Performance management should not only comprise SLA monitoring: “In performance management, it is important not only to conduct SLA monitoring and measurement, but to conduct it end-to-end, which is an extremely challenging task. If you have connected or interrelated services, how do you measure what comes out at the end? This end-to-end measurement is extremely difficult to implement in practice”, Interviewee [IIa]. Moreover, Interviewee [IV] highlights that performance management is important, but even more important for client companies is the question of what will happen if an SLA is violated and how they can readjust the service. Therefore, these issues need to be addressed in the contract negotiation, which is why we follow the suggestion of Interviewee [III] and Interviewee [IV] and designed an overlap of the performance management process with the contract negotiation process in our cloud management framework.

4.8 Termination management

Termination management copes with the deletion and the retransfer of data assets back to in-house systems or to another CSP. Thereby, the client requires the support of the original CSP. It is mandatory to clarify already in the contract phase how long client data will be stored for the transfer, what assistance will be given during the transfer, emerging costs, and when the information will be deleted in the contract management process (Expert Group 2014). The lack of contractually agreed data handling arrangements can either lead to loss of data when the CSP deletes all client data immediately after the contract suspension, or to compliance risks when client data are stored too long (Expert Group 2014; Hon et al. 2012). To avoid problems with the interoperability and transfer of data and applications (i.e., lock-in), clients need to ensure that the CSP supports interoperable standards (API, programming language, and runtime applications) (Opara-Martins et al. 2016). Furthermore, CSPs might also terminate a business contract, e.g., due to a shutdown of a certain service or if a client violates contractual terms. Thus, the client should develop business continuity plans. Also, the interview findings show that aspects of contract termination must be negotiated and “be confirmed in the contract, otherwise you will wake up badly at the end of the contract”, Interviewee [III]. Consequently, “it would be charming if a small part of termination management has an overlap with contract management because it is very important to define in the contract how terms of transition and/or exit look like”, Interviewee [III]. From a provider perspective, “we always make sure that when a client leaves that they go in good faith and in good will from both sides in terms like we host their assets, we always give them back, we always make sure that the client gets a hard drive or server back with all the data they once gave us”, Interviewee [Xa].

4.9 Relationship management

To guarantee a healthy client–provider relationship within the service provisioning, trust in the CSP's intentions and capabilities is a top priority for most companies (Garrison et al. 2012). The challenges of trust in cloud service provisioning do not entirely stem from the technology itself, but also the lack of transparency, control over data assets, and unclear security assurances (Huntgeburth 2015; Khan and Malluhi 2010; Habib et al. 2011). Thus, clients appreciate it if a CSP gives extensive information on products and security measures (Huntgeburth 2015; Khan and Malluhi 2010). Independent third-party certifications also certify the CSP’s capabilities to act as a quality verification as illustrated by Accorsi et al. (2011). Moreover, the client should establish routines to exchange performance and security monitoring resulting in service improvement purposes (Schlagwein and Thorogood 2014). Lacity and Reynolds (2014) also describe that a major challenge of cloud consumption is to keep the provider’s attention once the contract is running. Therefore, they suggest building social capital with cloud providers outside the formal cloud service relationship (Lacity and Reynolds 2014). We also find evidence in our interviews for relationship management. The intensity of the relationship management differs from nearly no contact (low-touch) to interaction in the spirit of a partnership (high-touch) (Interviewee [IX]). For high-touch relationships, relationship management is divided up between different teams of the CSP. For instance, in the pre-contract phase, the relationship management is part of the sales team, whereas “as soon as the contract is signed, every contract is handed over to the customer success team and the onboarding department. […] Relationship is definitely important, but the content is different [between the phases]”, Interviewee [Xa]. However, relationship and cooperation can also be difficult in rather low-touch relationships. “The support itself is largely outsourced to India and is divided into different support levels. We experienced that on the first and second level support the support quality was partly very low. But if the problem was not solved and you were routed to the support in the USA, then it worked well. But the issue of support from a major CSP is a difficult one”, Interviewee [IX]. As Interviewee [VIIIa] puts it, “If I need my credit card in the ordering process, then this is an indication that I will have little interactions with the provider”.

4.10 Risk management and legal regulations

To deal with cloud-specific risks, dedicated risk management is of fundamental importance (Fan et al. 2012; Tanimoto et al. 2011). The most prominent risks include data privacy, data security, compliance, and the availability of services that are often related to one another (Srinivasan et al. 2012). Also, some circumstances can reinforce risks (Keller and König 2014). Clients need a careful assessment of risks related to cloud sourcing, and need to develop risk management mechanisms and require appropriate business continuity plans for the impact of any predictable (and unpredictable) interruption event like a protocol of actions (Ristov et al. 2011). Applicable from traditional risk management, clients must identify threats throughout the cloud sourcing relationship as well as structure all risk-related matters in a way that decision-makers understand which risks exist and what factors can influence those risks. As cloud computing develops towards complex network structures, similar to supply chain networks, it is particularly important to analyze the impending network structure (Keller and König 2014). In doing so, organizations must accept that cloud computing has its own idiosyncratic risks that may not be solved through traditional risk management methods and thus requires new approaches (Paquette et al. 2010; Ramgovind et al. 2010). Hence, Zhang et al. (2010) analyze the applicability of a risk management framework for cloud computing. In accordance with the literature, the interview findings also show that data-related problems are the major issue among all challenges (Interviewees [IIa], [III]). “This is the most relevant and the greatest challenge. The transparency and security of having the data secure with the CSP and being able to retrieve it at any time. The most important challenge is not technology, but non-technical factors and IT security”, Interviewee [III]. Additional risks can also emerge from cloud provider networks. For instance, “If the underlying infrastructure CSP is not available, then the CSPs which run their cloud services on this infrastructure CSP also fail”, Interviewee [I].

5 Preliminary contingency factors for the cloud management framework

Our conceptual framework, despite being well-received by our interviewees, is contingent on salient factors of the client–provider relationship. While this theoretical lens has been adopted to discuss the locus of decision rights for SaaS cloud services (Winkler et al. 2011), to the best of our knowledge, research lacks a thorough understanding of cloud-specific management processes and their underlying contingencies.

Contingencies are moderating variables or influences that have a bearing on other variables (Glaser 1992; Sambamurthy and Zmud 1999). A better fit among contingency factors and their consideration in management choices might improve organizational performance (Weill and Olson 1989). Therefore, we decided to describe those insights in a preliminary contingency model that influences and moderates the cloud management framework. Sambamurthy and Zmud (1999) distinguish three types of contingencies according to the contingency factors’ influence on the outcome. With reinforcing contingencies, all contingency factors induce the same outcome. Likewise, dominating contingencies create one result, but the result follows one primary contingency factor. In contrast, conflicting contingencies do not allow a predominant result to be derived, because the different contingency factors demand contrasting management choices.

During data analysis, we compared the interview findings across the different cases and identified three contingency factors that influence the processes’ reasonability and configuration in our cloud management framework. Thus, our ten cloud management processes describe general fields of action for organizations to successfully use cloud services. Specifically, the management actions are contingent on client–provider ratio, specificity, and service delivery models. In the following, we elucidate these three contingency factors and potential adjustments of the cloud management processes as adequate responses to the contingency factors. Thereby, we explicate our preliminary findings regarding contingencies with two exhibits that emerged during data analysis.

5.1 Client–provider ratio, specificity, and service delivery models

The first contingency factor, client–provider ratio, describes the client characteristics compared to CSP characteristics. Building on our analysis, this ratio comprises aspects like client size and prospective cloud service user base, client knowledge and experience, client cloud ecosystem, provider size, and provider focus on client needs (Schneider and Sunyaev 2014; Benlian 2009; Vithayathil 2018; Lacity et al. 2017). Thus, while size is the decisive factor in the client–provider ratio, we dive deeper into the relevant aspects mentioned by our interviewees.

Regarding client size, our interviewees especially noted differences in negotiation position and cloud management professionality. The interviewees associated larger organizations with more negotiation power and higher cloud management professionality compared to smaller client organizations. “We could not discuss classic topics such as contract negotiation with Microsoft, as we are too small for this. For example, we could not deviate from the process at all.”, Interviewee [VIIb]. In addition, case IX illustrates that not only client size influences the client–provider relationship, but also the prospective user base of the cloud service. While case IX is a rather small fintech (< 40 employees), providing cloud services to this fintech is also a door opener to cooperate with the bank behind it (< 750 employees, < 50 bn € balance sheet total). Larger clients are more likely to feature knowledge and experience for cloud services which constitutes a prerequisite to face the provider at eye level and to use cloud services to their full potential. “The basic prerequisite is the understanding and knowledge of limitations within cloud solutions”, Interviewee [IX]. However, client size is also linked to the clients’ cloud ecosystem, which comprises interdependencies across multiple cloud services in a multi-sourcing environment, as well as interfaces to internal IT infrastructure (Schlagwein et al. 2014; Winkler et al. 2014). Consequently, companies must decide whether to adapt their infrastructure and processes, ensure integration, or build workarounds. “Often, some other company builds the middleware even though of course that is a hurdle itself. Someone needs to build the middleware where different APIs must talk to each other […] So that is something that is often taking a whole lot of time to research if this actually works”, Interviewee [Xa].

In terms of provider size, larger CSPs have a reputation for delivering better service quality compared to smaller cloud providers, but at the same time, they are less flexible. “You always have the trade-off between ‘I will take something big with high quality and little flexibility and room for negotiation’ or ‘I will take something smaller with less know-how, but a more personal relationship with more interaction and flexibility’”, Interviewee [VIIb]. Finally, our interviews indicate that the provider's focus on client needs differs in terms of the nature of cooperation and level of interaction between the client and the cloud provider. While cloud services are usually self-explaining and easy to use, clients often require assistance to integrate services into their existing ecosystem and to facilitate the interplay with other cloud services. “In the service transition, a lot of consulting effort is necessary, which does not work with every CSP”, Interviewee [IV]. Thus, the client’s effort and success in overcoming such obstacles depends on the provider’s focus on client needs. “You can buy a license and get started. But it is very unlikely that this will fit your needs. All services must be configured”, Interviewee [VIIb].

The second contingency factor, specificity, represents the continuum between specialized cloud services and commodity cloud services. While specialized services address particular requirements of certain industries or application scenarios (Keller 2019), commodity services are universally usable in various application scenarios (Schneider and Sunyaev 2014). Thus, clients must carefully evaluate which kind of service fits their needs best and adapt the cloud management processes accordingly. Although specialized services may better meet clients’ requirements, they also require increased interaction in the client–provider relationship. “In theory, if you have a tool like Office 365, you just download it, pay for it, and then you are good to go. So not every SaaS company needs to do it like us, but some SaaS software like [ours] also requires a little bit more human touch. Our tool would not be as successful as it is right now without approaching client success how we are”, Interviewee [Xa]. Moreover, the contract negotiation stage and the associated interaction differ significantly between commodity and specialized cloud services. For standardized commodity cloud services, CSPs offer little to no room for negotiation. In contrast, specialized cloud services often concern the client’s core business or core processes and, therefore, require more negotiation and client–provider interaction. “If I require a credit card for provisioning, I won’t have much interaction with the provider”, Interviewee [VIIIa]. Furthermore, service specificity also affects termination management. When using a specialized service, the client needs to keep control of the stored sensitive data and define appropriate termination management measures from the beginning of the contract to avoid losing important data. Case X provides interesting insights into the attempt to standardize termination management even for specialized cloud services and to ensure a consistent and standardized approach. “So we always make sure that when a client leaves that this goes in good faith and in a good will from both sides in terms like we host their assets, we always give them back, we always make sure that the client gets a hard drive or server back with all the data they once gave us”, Interviewee [Xa].

The third contingency factor, service delivery model, depicts the differences between IaaS, PaaS, and SaaS cloud service provisioning (Mell and Grance 2011). The three abstracted service layers are umbrella terms that comprise various technological aspects and typically reflect the different levels of abstraction of the offered functionality and the provider’s service model (Sunyaev 2020). Regarding the management of the three service delivery models, SaaS has the highest complexity and IaaS has the lowest complexity (Iqbal et al. 2016), as our interviewees also acknowledge. “So, I think especially for SaaS, the topic becomes more complex generally speaking, but there you still have to shed light on all points and discuss them with the clients”, Interviewee [Vb]. At the same time, the clients’ responsibility decreases from IaaS to SaaS. “IaaS, I would translate it this way, we don't have to worry about the hardware, but we can virtualize as much as we want. That means we buy the environment, so the virtualization machine, the servers, the storages, the databases or whatever, someone runs it for us, but what we put on it we have to manage and operate ourselves”, Interviewee [IX]. Although our interviewees attributed SaaS with the highest complexity in steering the CSP, SaaS’ technical complexity is rather low compared to IaaS or PaaS. “With SaaS, I just want the program to work and the usage to be smooth. With IaaS and PaaS, I have very different aspects such as I need more memory, I need more capacity, I need this or that feature, how fast or slow the processor is at the moment, or is there a specific bug that can blow everything up? Depending on the kind of ‘as-a-Service’ there are complex monitoring requirements. I think that the intensity [between the service delivery models] differs”, Interviewee [VIIb].

5.2 Contingency factors’ potential implications for the cloud management framework

During data analysis of our expert interviews, we observed that the identified preliminary contingency factors have different implications for the presented cloud management framework (see Fig. 1) and the contingent characteristics may alter the cloud management processes. In this section, we draw on two contrasting cases from our interviews to illustrate potential adjustments required to ensure the process effectiveness of our cloud management framework, i.e., case VII and case X. While the two cases consider all three contingency factors, they focus on selected manifestations of the contingency factors. On one hand, case VII is a small research institute using standardized PaaS cloud services from large CSPs with little experience in CSP management. On the other hand, case X is a small CSP offering a very specialized cloud service to larger clients. By juxtaposing case VII and case X, we contribute to a better understanding of how companies may adapt the cloud management processes according to their specifics. Table 3 summarizes the contrasting case characteristics.

Table 3 Overview of contrasting cases
Full size table

Naturally, the two contrasting case examples do not cover all potential combinations across the three contingency factors. Yet, by their fundamental differences, the two cases shed light on the tendencies for necessary adaptations that result from the contingency factors. Based on a synthesis of all our interviews, Table 4 summarizes the contingencies’ potential implications for the cloud management process for the two exemplary cases. We see this as a promising starting point for research to explore the contingency factors and their implications in more detail as well as for practice to use it as a preliminary guideline to find appropriate adjustments for the specific contingency factor manifestations in companies.

Table 4 Overview of the contingencies’ implications and potential adjustments
Full size table

The two distinct cases illustrate the potential adaptations to the management processes to account for the contingency factors. As an emerging theme during interview analysis, the contingency factors and their implications require further substantiation. Still, these preliminary insights provided us with a better understanding of the complex reality of the client–provider relationship. As illustrated in Sect. 2, researchers and practitioners often discuss cloud services as highly standardized commodities such as storage or computing power (Buyya et al. 2009; Dhar 2012; Maurer et al. 2012). However, with the increasing adoption of cloud services, we observe a diversification of cloud offerings. An increasing number of specialized cloud services target particular business user groups and business needs (Hoefer and Karagiannis 2010).

Likewise, our two exemplary cases fundamentally differ in their general nature. On the one hand, case VII is less complex regarding the client’s requirements and can follow clear CSP prescriptions and procedures for service implementation and use. On the other hand, clients in case X benefit from closer and needs-oriented interactions with the CSP which allows for client-specific adaptations of the cloud service in the broader sense (e.g., through additional services during service and organizational transformation). Owing to the lower level of CSP interaction, we conclude that case VII requires more client responsibility to achieve a successful cloud service. Hence, case VII is an example of the overall cloud computing paradigm, combining cloud computing’s infrastructural characteristics (e.g., scalability and resource pooling) and business characteristics (e.g., on-demand self-service) (Mell and Grance 2011) with a standardized and low-touch CSP interaction. In contrast, case X comprises primarily cloud computing’s infrastructural characteristics, while client and CSP forge the business characteristics through a high-touch CSP interaction. Therefore, organizations must carefully assess their desired cloud service, consider the three contingency factors, their implications, and the client–provider relationship to adapt the cloud management processes accordingly.

6 Conclusion and discussion

In our research paper, we contribute to cloud governance, specifically to the context of CSP management. Here, we provide a framework that illustrates ten processes on the client side that cope with CSP management. Furthermore, the paper elucidates preliminary contingencies that describe the reality of client–provider interactions in the cloud service provisioning. The framework and the contingencies originate from an extensive literature review corroborated with insights from 12 interviews with 16 industry experts. Thereby, our paper provides a starting point for organizations to successfully manage CSPs.

6.1 Theoretical contribution

Our research contributes to the general discussion on cloud computing governance and cloud provider management. The study’s findings reveal that today, besides commodity cloud services, also highly specified, complex cloud services exist. Therefore, we provide a structured framework on how companies can manage their cloud providers and interactions with them. We propose ten management processes covering the entire cloud sourcing lifecycle, which deepen the understanding of cloud sourcing relationships and their successful management. Also, other sourcing and B2B relationships may involve comparable characteristics (e.g., pay-per-use, scalability, non-storability). Here, our presented cloud management framework and the comprised processes may provide important insights for comparable disciplines and can serve as a valuable starting point.

Besides the framework, we provide two additional theoretical contributions: first, we focused on clients in the business-to-business context. The existing literature predominantly considers the provider perspective (cf. Xiao and Hedman 2019), concentrates on specific service models (cf. Winkler et al. 2014), or focuses on single case observations (cf. Schlagwein et al. 2014). We analyzed existing literature and added insights from multiple cases, thus, creating a comprehensive basis for future theory building of the client–provider relationship for cloud services. Second, we unravel the complex reality of client–provider relationships through three contingency factors that we synthesized from our data. We explicate their potential implications for our ten management processes by juxtaposing two distinctive cases. Our results indicate that, in cloud computing environments, client–provider relationships are neither fish nor fowl and require in-depth case-specific research. Thereby, we provide insights into the dimensions that span in this context and extend previous, often one-dimensional or procedural literature.

6.2 Practical implications

From a practical point of view, the results of our work are especially important for companies planning to capitalize on cloud technology while still being rather inexperienced in cloud management. In particular, the CSP management framework, as well as the identified contingency factors, will help IT managers to access and use cloud technologies more successfully. Furthermore, we support potential clients with managerial implications on how to manage CSPs and offer initial insights into how clients need to adapt their cloud management processes based on the two very different client-CSP characteristics provided.

Also, from the perspective of a CSP, our framework helps to identify crucial points for cloud providers within the service delivery process. Based on our identified management processes within the CSP management framework, clients and their CSPs can solve potential problems before they occur. Hence, the quality of the service delivery process may increase, and client satisfaction may rise.

6.3 Limitations and future research

Our research is subject to limitations that foster future research. First, our qualitative-empirical research approach cannot claim for generalizability. However, the interviews allowed us to explore the complexity of the client–provider relationship and delineate three preliminary contingency factors. Second, the contingency factors only emerged during data analysis and we could not confront our interviewees with our conceptualization of the contingency factors. Thus, future work may further elaborate on the contingency factors to validate our findings and foster the understanding of their influence on the cloud management processes. Third, we did not consider potential interdependencies between the contingency factors. Judging by the different implications in our two distinct cases, we expect conflicting interdependencies among the contingency factors. Moreover, we also assume that there are interdependencies between the cloud management processes. Therefore, additional research on these interdependencies would be fruitful to better guide decisions on the cloud management processes. Fourth, the topic of cloud provider management is a dynamic field. New technologies and paradigms are emerging, whereby cloud services also change. A longitudinal approach would be helpful to take these dynamics into account and observe the entire cloud service lifecycle. Besides, the interview partners also pointed out that cloud services will often accompany an entire cloud ecosystem and multi-sourcing (Goldberg and Satzger 2016). Our research contribution focused on the relationship with a single CSP. Thus, the investigation of the entire cloud ecosystem seems to be a fruitful topic for future research. Fifth, our paper focused on the development of the cloud management framework, building on an extensive literature study and 12 expert interviews. The demonstration and evaluation (Hevner et al. 2004) of the final cloud management framework goes beyond the scope of this paper. Hence, future research could provide explicit guidance for its implementation and observe its implications in practice. Developing a maturity model depicting actionable measures for different degrees of CSP management professionalism in each management process could be a sensible next step in this direction. Despite its limitations, we believe that our research is a step towards unraveling client–provider relationships, which is useful for practitioners and researchers alike.