Cloudy transaction costs: a dive into cloud computing economics

Looking merely from the neoclassical perspective, cloud computing is price effective. However, according to institutional and transaction cost economics, cloud customers should estimate other costs beyond the price. Such costs may not be known to cloud customers, leading to unmet expectations and implementation challenges. The aim of this paper is to study transaction costs of cloud computing from the customer perspective to make the cloud journey less cloudy, i.e. more informed and well planned. This paper applies transaction cost theory to cloud computing through a 360-degree industry analysis. Expert interviews with vendor, customer and consultancy sides were conducted to understand costs associated with cloud computing. Findings were validated through a case study. Findings of this research indicate that cloud has high ‘asset specificity’ due to change management costs, meta services costs and business process reengineering costs. Cloud also has a considerable level of ‘uncertainty’ asking for managing contracts, investing in cloud-specific monitoring solutions and consciously reviewing of the legal compliance. Finally, cloud has high ‘transaction frequency’, which compensates for the needed investments triggered by ‘uncertainty’ and ‘asset specificity’.


Introduction
Cloud computing has been massively booming in the last decade. The most adopted cloud computing definition is the one provided by the National Institute of Standards and Technology (NIST) [14,33,42,50]. It defines cloud computing as "a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (for example, networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service-provider interaction" ( [36]:2). Although the rapid provision is a big advantage, it needs to be handled carefully.
Rapid provision of cloud services, with minimal management efforts, have largely motivated for customers to adopt cloud [24,28]. Vendors, as well, over-use this aspect in their marketing activities. However, research has reported some interesting findings that should complement that. According to Bildosola et al. [9] cloud customers lack criteria and/or guidelines to get a full picture of what is required from them before going to the cloud. The cloud services market can be considered from a general standpoint unclear; hence, the profitability of using cloud services is mostly hindered by assumptions and trialing [19,41]. In some cases, "unexpectedly", cloud services cost more than the initial investment in terms of continuous maintenance and other hidden costs [61]. Choosing a cloud service is sometimes a difficult and costly process [3]. In a survey conducted on 250 IT managers, it was reported that more than 70% of companies that moved to the cloud were not aware of these costs following adoption. Lack of vendor transparency, continuous maintenance costs, and lack of cloud expertise play a role in unpredicted costs and implementation problems [34].
This should not mean that the 'minimal management effort' associated with the rapid provision is incorrect. The point is that this should not disguise other efforts needed before and after provision. Cloud helps companies in various ways such as with scalability and agility [52]. Our critique, however, is that these advantages are, in most cases, requires extra after-provisioning management efforts. Considerable management effort is needed for successful cloud adoption. This paper reveals some of the management efforts involved in adopting cloud.
Cloud computing needs a different view of analysis to understand the unpredicted costs. On one hand, following the neoclassical economic thinking, cloud services are cheaper than on premise services. This is because cloud services are chosen from an open market, where competition and economies of scale can lower the costs of these services beyond what can be expected on premise [21,29,40]. On the other hand, choosing and adopting the best suited service with the best price takes time, negotiation and involves other issues. Thus, an examination of cloud services through transaction cost economic can reveal hidden, cloud management efforts and costs that are not evident the neoclassical understanding.
The paper discusses first transaction cost economics and its application to information systems. The research methods are next presented followed by the findings and discussion of research. Finally, the theoretical implications and conclusion are reported.

Cloud computing
Youseff et al. [58] viewed cloud systems in five ordered layers; cloud application layer, cloud software environment layer, cloud software infrastructure layer, software kernel, and hardware and firmware [10,58]. By this order, using the concept of service-oriented architecture (SOA), Youseff et al. [58] demonstrated that each layer can be composed from the layers underlying it. For example, cloud applications can be formulated using services from software environment layer or infrastructure layer. At the same time, services can be used from the same layer; e.g. a payroll application may use an existing accounting application [24]. The most famous delivery model classification available in the academia is dissecting cloud services into software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS) [31,46,51,60].
Armbrust et al. [4] disagree to articulate the different services delivered by cloud computing providers. They reason this to the lack of coherent dissimilarities between those services. They explained that platform as a service and infrastructure as a service have commonalities more than differences. We also see that such classification is not vital in the transaction cost analysis. The results in this paper showed that issues of cloud transaction costs were applicable in IaaS, SaaS and PaaS.
Further, cloud computing can be classified with regard to deployment in organizations. This would result in four types of clouds; public clouds, private clouds, hybrid clouds, and community clouds [30,42]. A public cloud is a type of service that is offered by third parties using the internet [24,27]. Private cloud denotes the case in which the cloud is solely dedicated and owned by one company. In some cases, private cloud can be managed by third party [24]. Some organizations tend to host their critical data in private clouds while utilizing the advantages of public clouds for non-critical data; this is denoted as hybrid cloud [25]. A final deployment model is community cloud in which a group of organizations with shared interests use and manage the cloud services [31,35]. This paper applies to public cloud and hybrid cloud. Those are most dominant deployment types within the cloud customers. Findings of this paper can partially apply to private cloud and this still requires empirical justification.
This paper empirically contributes to the research of total cost of ownership cost of public and hybrid cloud computing.

TCO of cloud computing
Total cost of ownership (TCO) provides companies with a comprehensive overview on the cost factors, which enables better decision making. Applying the TCO approach on cloud computing is vital for cloud beneficiaries to avoid vague estimations of the added values and account for indirect and lifetime-spanned costs ( [12,44,49,53]). Table 1 shows a summary of cost areas of cloud computing TCO. This is classified according the TCO activities of Ellram & Siferd [18]. The table shows that the difference between service models when calculating TCO is only apparent in price. Other cost areas are more alike than different when it comes to calculating TCO according to service model. This does not imply that they are alike in monetary values. Nevertheless, they are alike in the inclusion of the various cost activities and cost areas.
Although research has been applying TCO on cloud computing for a decade or more, cloud customers are still struggling in getting a full picture of the cloud journey ( [9,3,34,61];). Studying the cost of cloud computing is a primary task that should not be treated trivially [5]. This paper extends the research of cloud computing economics by exclusively studying its transactions costs. This helps adjusting the TCO estimation of the cloud journey.

Transaction cost economics
In any business interaction, there are at least two parties involved. When an interaction happens between a vendor and a customer, a transaction is in place. When a customer buys a good or service from a vendor, the customer pays a price to the vendor. However, the cost of the bought service or good is not only the price. The transaction itself of buying a service or good has costs. Transaction costs refer to the costs linked with managing, monitoring and controlling a transaction [38,43]. Williamson [54,55] developed the transaction cost theory to study information asymmetry between vendors and customers. According to him; customers try to monitor and control a transaction through choosing the best way for its governance. The most direct way of doing that is through contracts. Nevertheless, contracts are always incomplete. This could be due to information asymmetry; information that only vendors know but not customers, or vise versa. Or, this could be due to the infeasibility of adding a clause to the contract for every scenario possible during a transaction.
Despite this incompleteness of contracts, they are one important form of governance between vendors and customers. Choosing between the governance forms depends on the dimensions of the transactions. Williamson [54] defined three dimensions characterizing a transaction: asset specificity, uncertainty, and frequency. These dimensions work as determinants of favored form of governance. In other words, governance form is the dependent variable while the independent variables are asset specificity, uncertainty, and frequency. For example, the higher the uncertainty around a transaction, the more structured is the selected governance form.

Transaction cost theory in IS
One of the most known transaction types in the economic history is the make-or-buy decision. This transaction includes many asymmetrical conditions, information, risks, legal expertise and others. All these conditions make a transaction for a make-or-buy decision more complex [56]. Such a transaction has been present in the information systems field for a long time. IT managers often find themselves hesitant between building their own systems in house or buying ready systems, which is referred to as IS outsourcing. In response, many researchers applied the transaction cost theory (TCT) in the IS outsourcing field.
Examples for those researchers include Ngwenyama and Bryson [37] who used the TCT to classify the total cost of information systems outsourcing. They introduced four types of costs: "(1) The cost of transaction information processing services, (2) Set-up/contracting cost, (3) The cost of monitoring and coordinating the activities of the vendor(s), and (4) Switching costs ( [37]: 354). Aubert et al. [6,7] explained in light of the TCT approach two motivations categories that drive firms towards outsourcing. The first motivation is efficiencybased. It evolves around cost efficiency and concentration on core business processes. The second motivation, political motivation, such as having difficulties in managing IS activities due to deficiencies in IS departments. The TCT and IS outsourcing literature raise some questions with regards to the cloud set up. For example, does all what we know about outsourcing decisions in the IS field translate to the emergent cloud context? What is the difference between cloud and outsourcing? Such questions were discussed by different researchers. They highlighted that the value chain of cloud computing is more advanced than that of IS outsourcing [10]. Thus, one can conclude that cloud computing is an advanced form of IS outsourcing. What applies to IS outsourcing can extend to the cloud [32]. For example, the first motivation for outsourcing highlighted by Aubert et al. [6,7]: efficiency-based, applies to cloud computing. Motivation for cloud computing include economies of scale and pooling of demand [21,29,40].
This paper studies the economics of cloud computing through applying TCE. It is evident that TCE has been applied to IS outsourcing. Accordingly, interesting insights can be reached for cloud computing as well. This Delivery ▪ Implementation, Configuration, Integration and Migration [33] ▪ Support [33] ▪ Initial training [1,33] Quality ▪ Backsourcing or Discarding [33]. ▪ System Failure [33].
Communication ▪ Evaluation and Selection of vendor [1,33] is in agreement with the argument of Yigitbasioglu [57]: TCE is a "powerful theoretical framework" to study cloud-computing economics.
It is important to note that some researchers applied other theories too to cloud computing such as resource dependency theory and diffusion of innovation theory (e.g. Nuseibeh [38]). However, these theories study the propensity of the organization to adopt cloud computing. In this paper, we assume that the decision is already made to go for the cloud. We aim at studying the costs of that decision since cloud advantages have become a business necessity. Further, some research applied other economic theories on cloud computing such as game theory and market equilibria [2,16,40]. However, such research focused on price competition (e.g Chaisiri et al. [13]) and more vendor side interactions (e.g between IaaS and PaaS). In this paper, using transaction cost theory, we focus more on the costs that a cloud customer incurs other than the price. Those costs, as well, were not apparent in previous cloud TCO research. Considering the pricing only had shown to be misleading and incomprehensive of the total cost of ownership.

Methodology
In this paper, we define cloud-computing transaction as a cloud customers' decision to adopt a new cloud service. To investigate those transaction costs, we employed exploratory research utilizing two methods; direct indepth interviews and case studies. We conducted 360degree industry view analysis through expert interviews. Experts from the vendor, customer and consultants sides were interviewed. The main criteria for selecting a consultancy-side expert is to have a special interest and experience in cloud computing projects. The criteria for the vendor-side experts is to have direct interaction with total cost estimations for cloud customers. As for the customer-side experts, it was important to have direct experience with cloud adoption projects and a current cloud computing related job. Table 2 highlights some of the characteristics of the selected experts.
Twenty-one (21) experts were contacted for interviews. A total number of thirteen (13) agreed to participate in the study; five (5) consultancy-side, four (4) customer-side and four (4) vendor-side experts. This number was sufficient because we reached a point where more interviews did not add something new to the findings. Additionally, we followed the expert interviews with a, case study. The case study is a 2000-employees company operating in 10 countries. It has a portfolio of cloud services including, SaaS, PaaS and IaaS.
Questions of the expert interviews were tested first with a former cloud computing sales person. This testing was vital to insure the reliability and validity of the questions. This helped in identifying areas of vagueness in the questions and clarifying them. We recorded interviews after obtaining necessary permissions. Recorded interviews were transcribed through speech recognition software. Manual review of the transcripts took place for adjustments. Then, text mining was utilized to extract and report findings.
The output of the expert interviews was graphically summarized and discussed/ applied in details with the case study's top management. The case study was built on three in depth interviews with IT top management and various documents such as vendor invoices and usage analysis.
The questions asked were aiming at exploring the cloud-specific extra investments as well as the costs for governing uncertainty. To formulate the questions, vendor reports were used such as Oracle adoption principles (OCAP) [39] and AWS adoption framework [8]. Also industry white papers such as Practical Guide to Cloud Computing.

Findings and discussion
This section presents and discusses the findings of the expert interviews and the case study conducted to investigate (hidden) transaction cost in cloud-computing transactions. Specifically, the findings of this paper show a number of transaction cost areas associated with the dimensions of cloud computing transactions, namely; cloud asset specificity, cloud uncertainty and cloud transaction frequency, as summarized in Fig. 1 and elaborated upon in this section.
Cloud asset specificity Williamson (1985), as cited in ( [43]: 337), defined asset specificity as "durable investments that are undertaken in support of particular transactions, the opportunity cost of which investments is much lower in best alternative uses or by alternative users should the original transaction be prematurely terminated". This means that a company might have to make special, investments for some specific transactions. Those investments might not be utilized for anything other than those transactions. In such a case, those transactions are of high asset specificity. Nuseibeh [38] views cloud asset specificity with respect to the ability of a cloud customer to move from a cloud vendor to another in a smooth manner. Yigitbasioglu [57] added that the amount of customization in a cloud service must also be considered in determining cloud asset specificity.
Looking at the original definition of Williamson (1985)as cited in (Shelanski and Klein, 1995: 337), he highlighted asset specificity investments that support a transaction. Accordingly, we define cloud asset specificity through defining the costs that the cloud customer incurs to only support the cloud service. This does not neglect the switching costs highlighted by Nuseibeh [38], nor the customization costs added by Yigitbasioglu [57]. We see those two points important, but the findings views them very incomplete in defining cloud asset specificity.
Hence, in order to determine asset specificity of cloud services, the findings added a number of cost categories. Quoting the definition of Williamson (1985), those costs are durable investments that are undertaken in support of a particular transaction, which is cloud service adoption in this case. The cost categories are: (1) Change management costs. (2) Meta Services costs. (3) Business Process reengineering costs. In other words, cloud asset specificity is a function of change management costs, meta services costs and business process reengineering costs incurred by the cloud customer. It is worth noting that change management, business process reengineering happen with other technologies. However, those two elements are very different with the cloud than with on premise. The following sections provide more details and reasoning.

Change management costs
According to the cloud vendor interviewees, all cloud vendors offer their customers free trainings until the customer is confident with the service in question. This is the usual marketing phrases all over the internet. However, the same vendor-side experts implied that there are other paid trainings. For example, Microsoft offers educational not-for-free Azure certifications to their cloud customers and to IT people upon request. Accordingly, cloud vendors themselves are refuting the concept of for-free, whenever-needed trainings that are being advertised. The for-free training does not build the needed cloud skills. From the customer perspective, switching to cloud is not a matter of mere training. Customer-side experts as well as the case study indicate that they needed to change the work style when cloud was introduced to the company. Project management methods had to change. Companies needed to move from a classical waterfall approaches towards an agile mindset. One of the experts added that they had to offer agile training to top management too. The IT team changes significantly: both the case study and the experts indicate that cloud asks for extending the IT team. For example, an expert stated that they had to hire extra employees to administer the email system of the company when it moved to the cloud.
Consultants supported the input from the customer-side experts. Furthermore, they stated that a cloud customer needs a change management strategy to support cloud adoption. They highlighted that this point is underestimated by cloud customers, and disguised by cloud vendors. For example, cloud not only asks for new employees, but also deletes some roles in IT department. The vendor-side experts directed their answers towards how the company can use those unneeded resources in other business units, however consultancy-side experts highlighted that you cannot move an IT caliber to, for example, the marketing department. As well, infrastructure, hardware caliber can not easily act as cloud specialists. Change, according to the consultants, has to be planned and managed. A resource with cloud experience is vital to lead this change.
This comes in line with predictions of Gartner [22]. They stated that CIOs play a vital role in changing the mindsets and practices of the whole organization during technological transition. Furthermore, Gartner anticipate that by 2021 CIOs will be equally sharing the responsibility for change management with chief HR officers. As well, Yousif [59] advised that CIOs need to be agile and flexible. Accordingly, change management comes with many cost parameters such as paid intensive trainings, hiring cloud skill, building change strategies and laying over outdated-skilled employees [26].

Meta services
Cloud computing is based on the "as-a-service" philosophy. A company may be interested to have email systems as a service for example instead of investing on building and managing that themselves. Unexpectedly, IT departments find themselves investing in other cloud services to manage this email-as-a-service. Consultancyside experts stated that companies usually have to buy services to track consumption, audit, migrate and ensure that they are getting optimal costs. Customer-side experts reported that their companies had to buy many third party services or sometimes build their own solutions to better manage the cloud portfolio. Findings from the case study similarly indicate that the cloud forced the company to increasingly adopt additional security services.
Such services that emerge because of the move to the cloud can be termed Meta service, by which we mean cloud services that manage cloud services. For example, Azure-costs.com is a cloud service to manage Microsoft Azure cloud services. Azure-costs.com is a third-party service, not offered by Microsoft. Companies pay for it separately. There are many other similar services and dedicated IT companies emerging and building their business models only on selling these meta services.

Business process reengineering costs
Interviewed consultants indicated that some companies have immature processes, which may disqualify them from moving to the cloud. Moving to the cloud in such situations would incur tremendous costs that may put the business at risk. Such situations call for business process reengineering (BPR) practices to accompany cloud adoption. According to the consultancy experts, vendors never mention such crucial step. Customers reported that they had to change some processes to move to the cloud and they still wish to change some more, but it is not a one-day task. Consultants commented that this step of business process reengineering is largely, naïvely-underestimated despite being complicated and vital for a cloud project's success.
The complication around and the importance of process reengineering arise from a number of reasons. One is that responsibility and process ownership is often vague. A marketing director can decide to purchase a SaaS for his sales personnel while unknowledgeable about associated security vulnerabilities. At the same time, the IT director in this situation may neglect these security vulnerabilities as the original SaaS purchase decision was not his. This complicates accountability if security is preached in such a grey situation.
Such a grey area of process ownership leads to another point of BPR importance for cloud scenarios. When an IT department is not adding any value to that acquisition or to the procurement of services, they create a "shadow IT" problem. In the case study of this paper, the CIO highlighted that this shadow IT is creating a headache to the IT department. He stated that business units get themselves in troubles with cloud vendors and IT is surprised with problems and unplanned projects to rescue the business units.
To eliminate shadow IT problems and make the IT department cloud-resilient, customer-side experts explained that a number of IT processes had to change. For example, the follow-up processes and the testing processes often need reengineering. One of the experts from the customer side stated that they had to change processes because some accounts generated bills of thousands of Euros in few days. IT department should also continue to seek more value-added activities to provide to the business units.
One consultant explained those value-added activities as the broker model. The IT department needs to act as a broker for cloud services. This entails that the IT department: (1) gives end-users some level of flexibility and access services on demand. This can be through an internal portal or marketplace where end-users choose the applications they need from it while the IT department actively adds new services to this marketplace. (2) Let individual departments own their budgets, while the IT is responsible for talking to multiple suppliers and negotiating contracts. And (3) ensure that certain levels of security and data protection are met. In these ways end-users get the flexibility they want, while IT departments have visibility and control of budgets, governance and security, controlling the emergence of shadow IT problem.
One customer-side expert explained that his IT department focused on building such a broker model. It showed positive results but called for many processes to be reengineered or created from scratch. As for the case study, the CIO showed resistance in changing the way the IT department is dealing with the business units. This, in return, caused conflicts with business units and he had to ask top management for support in enforcing the IT department's policies on business units.
From another perspective, business units are not only affected when they use a cloud service, but also some of them have processes to be reengineered. For example; supply-chain or procurement department should collaborate with IT and design a new process for evaluating cloud providers. According to consultancy side experts, a caliber from supply chain should engage in reviewing the contracts and periodically reviewing the performance of the cloud vendor in compliance with the SLA.
On the customer side, the experts and the case study showed the absence of such involvement with the supply chain department. They however reported the need for such procurement caliber. One consultancy-expert added that cloud adoption is a business issue where the steering committee or the project board has to include procurement, among other parties. Many companies hurry to move quickly and they don't necessarily get the best benefit from it.
Which resulted in many organizations that are unhappy with their cloud providers.
Another non-IT business process that requires reengineering is billing and cost allocation. Cloud customers face different pricing options and styles from vendors [2]. A customer-side expert explained that a vendor can charge the first five Terabytes over the storage a certain cost, but the second five Terabytes would affect the total cost of the storage. In addition, if a customer uses two Petabytes, it has a different calculation. How can the finance department split the costs across the different business units? Each business unit has its own consumption, and costs cannot just be evenly divided. Experts from the customer-side along with the case study reported this challenge of cost allocation. The process is getting trickier and asks for new cloud/finance caliber.

Cloud uncertainty
There is usually a level of uncertainty in any transaction. Williamson (1985) as cited in Yigitbasioglu [57] has defined two types of uncertainties as the following.
Applying that on cloud computing, uncertainty negatively affects the trust of cloud customers [11,48]. The findings of this study shows a number of uncertainty areas and their implied costs; namely, contract management, monitoring and legal compliance.

Contract management
Transaction costs relate to the time and effort to reach, negotiate, contract, and maintain a relationship with vendors or customers ( [57]: 195). Cloud computing is marketed by vendors and perceived by customers as an easy choice with different advantages and a couple-ofhours adoption process. However, the real adoption cases showed that cloud is a complex economic set up that needs a more complex contract. Accordingly, contract management is inevitable for a cloud scenario.
Consultancy-side experts explained that vendors usually ensure that the terms of contracts are in their favor. Most SLAs allow the vendor to prevent the client form getting access to his data at any time. Contracts should clearly tackle disaster recovery and service failure penalty. In some cloud contracts, security is not guaranteed, in the contract clauses. In other words, the vendor is not clearly held responsible. This does not deny the fact that, in some cases, cloud can be more secure some on premise solutions. But the argument here is that vendors write the contracts in their own favors. One of the interviewed vendor experts stated that the contracts and service level agreements are used by the clients worldwide and the vendor is not welcoming to tailor them to specific customer concerns.
From the cloud customer perspective, the customer is neither ready for contract management nor fully aware of the contracted subject. Contracts are put to govern a technology that is evolving and agile by nature. Customers do not have prior experience with that. In the case study of this paper, the CIO explained that they had a problem to properly size the contracted service. Once a size was determined, the company got restricted with consumption limits and payments terms. According to an expert from the consultancy side, contract management is one of the things that companies overlook and it turns out to a surprise. Cloud customers need to negotiate the contracts and build plans before engaging in a cloud initiative.
Such negotiation of the contracts calls for a number of issues. First, cloud customers do not have the needed negotiation skills. As a result, consultancy-side experts suggested three entities who can help in this matter: Supply chain department, Legal department and/or external legal consultant. A cloud customer can utilize the skills of the supply chain department in negotiating and managing contracts. This is however new. The roles are changing. The IT department should collaborate with the supply chain department and the legal department to build such new skill of cloud service sourcing and contract management.
Further, consultancy-side experts highlighted that contracts and service level agreements are a very tricky part of cloud adoption decision and vendors are very careful in drafting contracts and put most of the risks on customers' side. This means that a large organization might be putting a mission-critical system under that arrangement. That is why the external legal expertise can be a costly, yet important, option in contract management. An entity with experience in cloud contracts should navigate the information asymmetry of the contracts. Investing in understanding and negotiating the contract is pretty important because it is very hard to go back once you got a contract and arrangement in place that is of 3 or 5 year time horizon.

Monitoring
Although monitoring is something that businesses should be undertaking using cloud or not, cloud is calling for cloud-specific monitoring tools. 'Cloud end users act with cloud services like a teenager with a credit card' said a consultancy side expert. They keep consuming the service while unaware of the costs they are incurring. A customer-side expert explained that some end users in his company incurred thousands of euros in a very short amount of time. The IT department had to interfere and terminate those accounts. Thus, monitoring is very important in the cloud set up. If not wisely monitored, cloud generates many unnecessary costs.
The question here is who should be monitoring what? There are the usual three players in the cloud setup; the cloud vendor, the customer's IT department and the cloud end-user (in IT or non-IT business units). From one side, the IT department has to monitor the cloud provider. This occurs through monitoring the adherence to the service level agreement. A consultancy-side expert recommended that companies should set up some internal benchmarks against which they can continuously compare the SLA. On the other hand, the IT department has to find a way to put limits and threshold on the end-user so as to get notifications when costs becomes too high.
Although monitoring is important to control costs, monitoring itself is a cost generator. First, to enforce limits and thresholds, IT departments need monitoring tools. In such case, three scenarios exist. (1) The vendor might offer free-of-charge functionalities to help the cloud customers monitor their consumption. (2) The cloud customer might opt for adopting third-party cloud services to monitor the cloud service. This is an example of Meta services mentioned in this paper. (3) Some cloud customers might prefer to build their own monitoring tools. One customer-side expert reported that his company is already using the three scenarios together. The case study reported that the vendor free-of-charge functionality give them alerts only when they consume all their allowed budgets not when a single account overuse the service for example.
Another monitoring cost is the cost of a monitoring resource. This was suggested by consultancy-side experts and approved through the case study. The cloud customer has to dedicate a resource to be responsible for monitoring the vendor in terms of reviewing the SLA. This includes the costs of recruiting the resource or training an existing resource in the IT department. Again this resource is dedicated to monitoring cloud computing only which is of high asset specificity. One more monitoring cost is charging back the business units. IT department has to allocate the aggregated invoices sent by the vendor. This is a tedious task and considerate time from the top management. However, it is important that the business units see their consumption and if they are exceeding their threshold because they will pay for it.

Legal compliance
Legal compliance becomes more risk-prone with the usage of the cloud. This is because data might be crossing oceans (van der Werff et. al, 2019). Is that violating the laws of the customer's country? According to a consultancy-side expert, "most companies don't know. They have no idea and their legal office may never have considered that issue". The vendors focus on their marketing activities and selling procedures. They are not going to tell if there is a potential problem. Yousif [59] suggested that cloud providers should have global presence due to data compliance and legal requirements. Both the case study and the experts agreed that there is a lack of caliber in the legal department to work on cloud-related issues such as data residency. This lack of caliber is in the law community in general as the legislation around the cloud is evolving continuously [57]. The findings of this study report that cloud customers need external legal consultancy to investigate compliance with laws. Unfortunately, this is not a one-time task. It has to be updated frequently since the cloud and its legislations are changing.

Cloud transaction frequency
Frequency means how often the transaction repeats. Williamson explained that the more a transaction repeats, the more it pays off to invest on its specific assets [23]. We identify cloud transaction frequency as how often services are adopted and how often a service is called. The findings show that cloud transactions have high frequencies especially in IaaS and PaaS. This is supported by the pay-asyou-go and/or scalability facilitated by the cloud. This, in return, means that investing cloud-specific assets-such as business process reengineering activities and change management practices-is worth it. This in return support our debate in this paper. We debate that this paper is not a cost-benefit analysis. This paper demonstrate the transaction costs to make a cloud journey less cloudy, i.e. more informed and well planned.

Theoretical implications
The findings have some important theoretical implications. We theorize that transaction costs of cloud computing is a function of the costs incurred through (1) change management, (2) Meta services, (3) Business process reengineering, (4) contract management, (5) Monitoring, (6) Legal compliance management. Although our findings show that these cost areas are indispensable for the success of cloud project, quantitative research gurus might question the significance of these costs. This is a normal debate between the quantitative and qualitative pillars. Thus, a suggested future direction is to test these theorized results quantitatively.
Another important theoretical implication is the effect of our results on the total cost of ownership calculations of cloud projects. The cost areas theorized by this paper should be included in the cloud TCO frameworks.
As well, this paper asks to handle the definition of cloud computing with care. The most cited cloud computing definition is by NIST. The definition associate 'minimal management efforts' to cloud computing provision. The findings of this paper highlight other management efforts after the provision of a cloud instance. As well, the release and provisioning might not be a straight forward task. Sometimes, a company have to build/ adopt a solution or write codes to decide when to release and when to provision. Otherwise, the cloud costs would offset the benefits.
Finally, this paper conceptualize a new term, Meta services. We define Meta services as 'services that are of high assets specificity to the cloud'. In other words, these are cloud services to manage cloud services. A company might adopt a monitoring cloud service to monitor its cloud infrastructure. The Meta service here is the monitoring service.

Conclusion
Looking merely from the neoclassical perspective, cloud computing is price effective. However, according to institutional economics and transaction cost economics, cloud customers should look beyond the price. This paper applies transaction cost theory on cloud computing. The results shows the following: Cloud has high asset specificity due to change management costs, meta services and business process reengineering costs. Cloud has a considerable level of uncertainty asking for managing contracts, investing on monitoring and consciously reviewing the legal compliance. Cloud has high transaction frequency, which compensates the needed investments triggered by uncertainty and asset specificity.
This paper is not a cost-benefit analysis. This paper studies transaction costs of cloud computing from the customer perspective to make the cloud journey less cloudy, i.e. more informed and well planned.

Authors' contributions
One author prepared this manuscript. The author designed the work, collected the data and analysed the data. The author wrote and revised the manuscript. The author read and approved the final manuscript.

Funding
The author has a PhD funding from the Brandenburg University of Technology.

Availability of data and materials
The data that support the expert interviews are available on request from the author. Data are not publicly available because they contain confidential data of the interviewees' workplace. Restrictions apply to the availability of the case study data based on the request of the interviewed top management of the company subject to the case study.

Competing interests
The author declares that there are no competing interests.