• Aucun résultat trouvé

Dealing with uncertainties in platform services

N/A
N/A
Protected

Academic year: 2021

Partager "Dealing with uncertainties in platform services"

Copied!
40
0
0

Texte intégral

(1)

Dealing with Uncertainties in Platform Services by

Arvind Karunakaran

M.S. Information Sciences and Technology Pennsylvania State University, 2011 B.E. Computer Science and Engineering

Anna University, 2001

SUBMITTED TO THE MIT SLOAN SCHOOL OF MANAGEMENT IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF

MASTER OF SCIENCE IN MANAGEMENT RESEARCH AT THE

MASSACHUSETTS INSTITUTE OF TECHNOLOGY

SEPTEMBER 2015

02015 Massachusetts Institute of Technology. All rights reserved.

The authors hereby grants to MIT permission to reproduce and to distribute

publicly paper and electronic copies of this thesis document in whole or in part in any medium now known or hereafter created.

Signature of Author:

Signature redacted

Arvind Karunakaran Sloan School of Management August 3, 2015

Signature redacted

Certified by:

-Accepted by:

Signat

M AC HI S INSTITU

OF TE-CHNOLOGY

JAN 262016

LIBRARIES

Wanda J. Orlikowski Alfred P. Sloan Professor of Management Professor of Information Technologies and Organization Studies

ure red acted

Thesis Supervisor

Catherine Tucker

E Professor of Management Science

(2)

Dealing with Uncertainties in Platform Services by

Arvind Karunakaran

Submitted to the MIT Sloan School of Management on August 3, 2015 in Partial Fulfillment of the Requirements for the Degree of Master of Science in Management Research

ABSTRACT

Platform services - services that are provided to organizations through online platforms - are increasingly being adopted and used within firms. The novelty of these services is generating uncertainties for both providers and customers. As these uncertainties and their consequences are not well understood in the existing literature, our research focused on articulating the nature of these uncertainties and explicating how they are being managed by providers of platform services. We conducted an 18-month field study of a platform service in the enterprise cloud computing industry, and found uncertainties associated with a number of concerns over the platform's privacy, security, flexibility, capacity, responsiveness, and innovativeness, and about the trustworthiness and credibility of the platform provider. We identified five mechanisms that the platform provider employs to manage these concerns - architecting boundaries, enforcing safeguards, segmenting customers, producing trust rhetoric, and articulating trust indicators. The first three mechanisms can be seen to constitute platform work - the work of designing, safeguarding, and keeping the system up and running so as to ensure the reliability of the platform, while the latter two mechanisms constitute trust work - the work of producing and disseminating a trust rhetoric so as to assure customers and prospects of the accountability of the platform provider. We found that both platform and trust work entail practices of materialization that normalize the uncertainties by downplaying certain concerns (privacy, capacity, responsiveness, credibility), while emphasizing others (security, flexibility, innovativeness, trustworthiness). Our findings highlight the enactment of uncertainty management, showing how reliability (of the platform) and accountability (of the platform provider) are performed in an ongoing manner, with important implications for the delivery of platform services to firms.

Thesis Supervisor: Wanda J. Orlikowski

Title: Alfred P. Sloan Professor of Management; Professor of Information Technologies and Organization Studies

(3)

Introduction

Uncertainty has long been an important area of focus in organizational research (Beckman, Haunschild, and Phillips 2004, Cyert and March 1963, March and Simon 1958, Milliken 1987, Weick and Sutcliffe 2007). As Thompson (1967) notes, "uncertainty appears as the fundamental problem for complex organizations, and coping with uncertainty as the essence of the administrative process" (p. 159). Two recent trends have made the issue of uncertainty more salient in contemporary organizations. The first is the shift to a service-based economy (Bell 1973, Chesbrough and Spohrer 2006), and the second is the delivery of services through online platforms' (Vaquero et al. 2008). The former has paved the way to increasingly complex inter-organizational relationships (Barrett and Davidson, 2008, Zysman, 2006), while the latter has made these relationships more impersonal as services are delivered remotely to thousands of organizations through the Web (Urban, Sultan and Qualls 1998).

This increasing prominence of platform services in organizations raises new questions about how uncertainty is managed by platform provider firms and with what consequences. Prior research on uncertainty has examined structural, symbolic, and relational approaches that organizations typically employ to manage uncertainty. These approaches have identified mechanisms such as using "loosely coupled structures" (Weick 1976, Weick and Sutcliffe 2007) in responding to uncertainties, buffering the "technical core" of an organization from environmental turbulence (Thompson 1967), imitating "best practices" of industry leaders (Greve 1995, Haunschild and Miner 1997), engaging in frequent communication and cultivating embedded relationships with boundary spanning members of customer organizations (Gulati 1995, Zaheer et al. 1998), and leveraging institutional norms, codes of conduct, and legal provisions (Bachmann and Inkpen 2011, Pavlou 2002, Zucker 1986) as ways to manage uncertainties. In the context of platform services, however, these mechanisms may not be able to fully explain how uncertainties are managed. First, uncertainties are always emergent and contingent in these contexts, and therefore very difficult to be pre-specified. Moreover, customers' data resides physically alongside other customers' data in shared data centers that are controlled by the provider. As the day-to-day management of these data centers are sub-contracted to third-party firms, more unpredictability is introduced, which reduces control and poses "severe new security issues not encountered by on-premise computing behind firewalls" (Brynjolfsson, Hoffman and Jordan 2010, p.33). Consequently, structural approaches, although relevant, may only help to a limited extent in handling uncertainties. Second, in the context of platform services, the technology, business model, and industry context is nascent. Therefore, there are no clear industry leaders whose practices can be imitated by firms. Neither are there established professional associations where firms can

' We use the term "platform" here to refer generally to "computing platform" - the specific configuration of hardware and software that supports the execution of various business application programs such as customer relationship management, payroll processing, and enterprise resource planning.

(4)

go to in order to learn about "best practices" concerning the governance of platform services and espouse those practices to signal legitimacy. Hence, the symbolic approach has limited applicability in this context. Third, the interactions between members of the provider and customer organizations are infrequent (Armbrust et al. 2010). The provider of platform services develops and maintains a platform through which services are delivered to customers in an "all at once" manner, thereby reducing direct interactions and personal communication. Moreover, customer data resides at a site controlled by the platform provider who has visibility to sensitive data (e.g., account details, sales deals, proposals, transactions), while the implementation of the platform (including algorithms and data mining techniques) are invisible to customers (Bezemer and Zaidman 2010). Consequently, this context is characterized by limited transparency and high knowledge asymmetry. In addition, this context entails a dearth of codes of conduct and legal provisions that firms can leverage to influence relationships, and in the process, manage uncertainties. Therefore, relational approach too has limited applicability in the case of platform services.

Moreover, the structural, symbolic, and relational approaches have given little attention to the role that technology - and materiality more broadly - plays in the management of uncertainty. This is a significant gap considering the critical role that technology plays in contemporary service delivery to organizations. This is especially so in the context of platform services, where massive data centers are used to host the servers and applications, data models and complex platform architectures are used to deliver services at a distance, native (i.e., platform-specific) programming languages to design and render applications, and algorithms and predictive modeling tools for mining the customer data.

Our research, therefore, is centered on identifying the concerns that constitute the uncertainties

generated by platform services, understanding how they are managed by the provider of platfonn services, and with what consequences. In this task, we specifically focus on the role that materiality plays in

uncertainty management. Our research involved an 18-month field study, supplemented by archival analysis, of a platform service - SigmaCloud2 - in the enterprise cloud computing industry. We studied the SigmaCloud platform from the vantage points of its provider (Sigma) and two customer organizations (Energy Corp. and CommHousing).

Based on our inductive analysis, we identified a number of concerns that constitute the uncertainties generated by platform services - concerns over the privacy, flexibility, security, capacity, responsiveness, and innovativeness of the platform, as well as concerns over the trustworthiness and credibility of the platform provider. We found that Sigma enacted five mechanisms to manage these uncertainties. The first three mechanisms - architecting boundaries, enforcing safeguards, segmenting customers - constitute what we call platform work and entail practices for designing, safeguarding, and keeping the platform up

(5)

and running so as to ensure its reliability. The latter two mechanisms - producing trust rhetoric and articulating trust indicators - constitute what we call trust work and entail practices that assure customers and prospects of the accountability of platform provider.

We found that together platform and trust work "normalize" uncertainties by downplaying concerns over privacy, capacity, responsiveness, and credibility, while emphasizing concerns over security, flexibility, innovativeness, and trustworthiness. Furthermore, platform and trust work objectivize these "matters of concern" by rendering them into "matters of fact" (Latour 2004) through various metrics, indicators, and rhetorics. Our study, thus, contributes an understanding of how uncertainties are managed by platform provider firms in the digital economy. Specifically, we make two contributions to organizational scholarship. The first, empirical contribution, identifies the various concerns that constitute the uncertainties regarding the delivery of platform services to firms, and elaborates the mechanisms and implications of managing uncertainties in practice. The second, theoretical contribution, explicates the constitutive role played by materiality in managing uncertainties and the organizational consequences. This focus on materializations in practice, in turn, allowed us to develop a performative approach to managing uncertainty. Such an approach articulates how the ongoing materializations (of the mechanisms) play a constitutive role in defining (and shifting) the meaning and boundaries of uncertainty in an online world.

Literature on Managing Uncertainty

The question of how firms manage uncertainty - commonly defined as "the difficulty firms have in predicting the future, which comes from incomplete knowledge" (Beckman et al. 2004, p.260) - has been a central one in organizational theory (Cyert and March 1963, Haunschild and Miner 1997, March and Simon 1958, Thompson 1967, Weick and Sutcliffe 2007). Research on the management of uncertainty that is relevant to our study can be understood through three streams of work.

The first research stream focuses on structural approaches to managing uncertainty. This line of work views uncertainty as primarily emerging from "a lack of internal control" (Jauch and Kraft 1986, p.778) pertaining to the structures and processes within the organization. For example, March and Simon (1958) argued that uncertainty emerges due to the production control and inter-divisional issues occurring within an organization, and proposed internal structural arrangements to reduce uncertainty and its impacts. Thompson (1967) recognized the importance of buffering the "technical core" of an organization from uncertainty, and theorized about various coordination mechanisms (e.g., sequential, pooled, reciprocal) that firms could use to reduce uncertainty. Other scholars have proposed the use of "loosely coupled structures" (Weick 1976, Weick and Sutcliffe 2007) and "semi-structures" (Brown and Eisenhardt 1998) as a way for organizations to reduce uncertainty. Empirical studies within this research stream have shown how internal structural arrangements for managing uncertainty shape important organizational outcomes such as external partner selection (Beckman et al. 2004) and governance (Carson et al. 2006, Huber et al., 1975). The

(6)

overarching focus of this stream of work is on how organizations can structure themselves, oftentimes in a

contingent and heterogeneous manner, when responding to uncertainty (Lawrence and Lorsch, 1967), and in the process, achieve consistency in the quality of outcomes.

The second research stream focuses on symbolic approaches to managing uncertainty, examining specifically how firms deal with the external environment (Cornelissen 2012, Neu, Warsame and Pedwell

1998). A core insight from this line of work is that organizations imitate others, when responding to

uncertainty, both to economize on search costs (Cyert and March 1963) and to render their governance practices legitimate to customers, prospects, and other stakeholders (Meyer and Rowan 1977). A large body of empirical work has shown why and how organizations turn towards imitation to manage uncertainty

(e.g., Greve 1995, Rao et al. 2001), the various imitation strategies that firms adopt in response to different

sources of uncertainty (Haunschild and Miner 1997), and its implications on firm performance. This line of work also highlights how firms leverage existing institutional norms and professional associations to signal their governance practices as legitimate to constituent stakeholders (Bachmann and Inkpen 2011, Pavlou

2002).

The third research stream focuses on relational approaches to managing uncertainty, such as communicating with boundary spanning members of the customer organization (Gulati 1995, Zaheer et al.1998), cultivating embedded relationships with customers and exchange partners to facilitate joint problem solving (Uzzi 1997), and transacting with a select set of partners with whom the firm has had previous experience (Podolny 1994). This line of work shows how firms use existing codes of conduct and legal provisions to influence relationships with customers and other stakeholders to manage uncertainties

(Zaheer et al.1998, Zucker 1986).

Looking across these three streams of research, we see that the approaches to managing uncertainty that have been identified to date are based on mechanisms that use structural arrangements such as "loosely coupled structures" (Weick 1976, Weick and Sutcliffe 2007) and "semi-structures" (Brown and Eisenhardt

1998) to handle and respond to uncertainties, buffering the "technical core" of an organization from

environmental turbulence (Thompson 1967), imitating "best practices" of industry leaders to signal legitimacy (Greve 1995, Haunschild and Miner 1997), engaging in frequent communication and cultivating embedded relationships with boundary spanning members of customer organizations (Gulati 1995, Zaheer et al. 1998), and leveraging institutional codes of conduct and legal provisions (Bachmann and Inkpen 2011,

Pavlou 2002, Zucker 1986).

These mechanisms, although relevant to certain extent, may not fully explain how uncertainties are managed in the context of platform services. First, in these contexts, uncertainties are always emergent and contingent - and therefore very difficult to be pre-specified. In addition, customers' data resides physically alongside other customers' data in shared data centers that are sub-contracted and managed by third-party

(7)

firms. This in turn reduces control and exemplifies unpredictability. Therefore, the structural approach can

only help to a certain extent in handling uncertainties. Second, since the technology, business model, and industry context is nascent, there are no clear industry leaders whose practices can be imitated by platform provider firms. Moreover, obtaining information about the environment and/or best practices from professional associations is also not possible, as there are no such associations present. Therefore, the symbolic approach too has limited applicability in this context. Third, as these services are provided through online platforms "at a distance" and in parallel to thousands of customer organizations, there is less scope for direct interactions and relationships between providers and customers (Armbrust et al. 2010). Moreover, since customers' data and activities are visible to and can potentially be tracked by the platform provider, while the implementation and operation of the platform is invisible to customers (Bezemer and Zaidman 2010), there is limited transparency and high knowledge asymmetry in this context. In addition, since the institutional norms and legal provisions within platform services are both nascent and unsettled, with few guidelines, codes of conduct, and service level agreements, it becomes difficult to leverage these to influence relationships and manage uncertainties. Therefore, the relational approaches too has limited applicability in the context of platform services.

In short, the structural, symbolic, and relational approaches may not fully explain how uncertainties are managed in the case of providing platform services to organizations. Moreover, such platform services depend critically on technology (and materiality, more broadly), an aspect not considered by existing organizational research on the management of uncertainty. This lack of attention on materiality is especially concerning, given the constitutive role that technologies such as data centers, data models, architectures, programming languages, and algorithms play in providing services within a cloud computing environment. We addressed these issues by examining how the management of uncertainties was materialized in the providing of platform services to organizations. A focus on materializations (Introna 2011, Orlikowski and Scott 2014) views materiality not as a "thing" that mediates, facilitates, or anchors some pre-existing processes and mechanisms, but as the ongoing, dynamic, and constitutive performance of those processes and mechanisms. By examining how management of uncertainties for platform services is materialized in practice (Scott and Orlikowski 2014), we were able to identify an additional approach to uncertainty management that focuses on the ongoing materializations of mechanisms for managing uncertainty. In such an approach, the meaning and boundaries of uncertainty are performed in practice, with significant consequences for platform providers and customers.

Research Setting and Methods

We investigated our research questions through conducting an 18-month inductive field study, supplemented with a detailed historical analysis, of SigmaCloud - an enterprise cloud computing platform delivered as a subscription-based "service" over the Web. Inductive analysis is particularly useful to explore

(8)

understudied phenomena (Eisenhardt and Graebner 2007) as well as to develop alternative insights about prior concepts (e.g., Sutton and Hargadon 1996) that can then serve as the basis for theory building (Edmondson and McManus 2007, Yin 1994).

Research Context

The SigmaCloud platform is a Customer Relationship Management (CRM) service provided by Sigma and used mainly by salespeople within firms to manage sales-related processes (e.g., the tracking and updating of sales leads and associated information). As the primary research locus for our study, it served as a "strategic research site" (Merton 1987) for our focus on the management of uncertainty. SigmaCloud was developed as a cloud-based approach for providing software applications to organizations via the Web. Instead of licensing, installing, and customizing packaged software in-house, customers can subscribe to the SigmaCloud platform and pay for services based on usage. This approach enabled Sigma to continually develop and update new features (with three major releases per year) to all the customers at the same time, without incurring problems with multiple versions that were prominent in the case of packaged software.

While a cloud-based platform approach showed promise, a number of uncertainties emerged. Since customer data were stored on shared servers in centralized data centers, concerns were raised about security and privacy. In addition, since both server space and platform resources are shared across customers, capacity of the platform became an issue with concerns over one (or more) customers monopolizing the use of shared resources. Despite such concerns, Sigma has grown rapidly, from a few thousand customers in the early 2000s to over 70,000 customers in 2013, generating over two billion dollars in annual revenues. Data Collection

We used ethnographic data collection techniques (Miles and Huberman 1994) over time and across multiple sites and a grounded theory approach (Strauss and Corbin 1990) for our study. These were supplemented with in-depth qualitative analysis of archival materials (Gaddis 2002). Our data collection and analysis unfolded in an iterative manner over time (See Table

1

for the list of data sources).

--- Insert Table

1

about here

---Archival materials. We employed historical methods to collect and analyze considerable amounts of archival data and publicly available materials (on the cloud computing industry, Sigma, and the SigmaCloud platform.) Burgelman (2011) notes that historical methods are useful "to document the intersection of continuities and contingencies, and the effects of context on outcomes" (pp. 594-599). We found this approach particularly helpful in developing a contextual understanding of the development of Sigma and the cloud computing industry over time.

We collected publicly-available data about the company (Sigma), the platform (SigmaCloud), and the industry (enterprise cloud computing), following the processes employed in past studies that drew on archival data for qualitative analysis (e.g., Danneels, 201 l;Joseph and Ocasio, 2012, Rindova and Kotha,

(9)

2001). First, we collected data to understand the trajectory of the "enterprise cloud computing" industry from a number of data sources. Second, we collected publicly-available information about the trajectory of Sigma and the SigmaCloud platform, which helped us construct a chronology of events in Sigma's history. Third, we programmatically parsed the Sigma Online Discussion Forum for a specific set of keywords to historically track the various issues that customers faced and reported over time, as well as Sigma's response to these concerns.

For data on the industry, we used several keywords ("cloud", "cloud computing", "enterprise cloud computing", "on-demand", "SaaS", "PaaS", "IaaS", "Software-as-a-Service", "Platform-as-a-Service", and "Infrastructure-as-a-Service") to search different databases (ABI Inform, EBSCO Business Source Premier, Lexis-Nexis Academic, and Information Sciences Abstract) for press articles related to enterprise cloud computing. We also gathered reports on enterprise cloud computing from industry analyst firms such as Gartner, Forrester, IBIS World, International Data Corporation (IDC), and S&P's NetAdvantage. We subscribed to newsfeeds from websites (such as Businesscloudnews.com, Cloudtweaks.com, Cloudtimes.org, and Cloudcomputing-news.net) and newsletters (such as Cloud Sherpa's Cloud Chronicles) that tracked industry events related to cloud computing. We looked for information that helped us understand the emergence of the enterprise cloud computing, the different players within the field, and how incumbents (such as the packaged software providers) reacted to cloud computing within enterprises. We then filtered this data to highlight concerns expressed about the uncertainties of cloud computing by industry analysts, technology journalists, packaged software providers, CIOs, and business users. We also tracked the responses

offered by different cloud platform providers.

For data about Sigma and its platform, we used company-related keywords (anonymized) to search several databases (ABI Inform, EBSCO Business Source Premier, Lexis-Nexis Academic, and Information Sciences Abstract) for relevant press articles. We also collected numerous documents about Sigma over time (e.g., press releases, annual reports, analyst reports, earnings call transcripts, SEC filing, employee blog posts, online videos, technology-related release notes). We also collected different versions of artifacts at Sigma related to managing uncertainties, including external audit reports, privacy and security statements, contracts and master service agreements for various services offered by Sigma, policy documents, advertisement campaigns, and third-party secured seals (e.g. Verisign, TRUSTe). .

We systematically parsed the Sigma online discussion forum using a specific set of keywords (e.g., "service disruption," "system down," "performance degradation," "performance issues," "fail", "error," "bug," "trust," "privacy," "reliability," "security," "uncertainty," etc.) to track the various issues that customers faced and reported over time. We also recorded Sigma's response to the concerns

(10)

reported by customers. We synthesized these materials to create a chronology of events (Van de Van and Poole 1990) relating to Sigma and its platform that helped us examine the various uncertainties that Sigma faced over time, and how it had addressed them.

Interviews and Observations. Our primary data were drawn from interviews and observations that unfolded over an 18-month period (between May 2012 and November 2014) at multiple sites. We began our data collection within the platform provider's site. The first author visited Sigma and conducted multiple interviews across business units dealing with sales and service, strategy, platform governance, software engineering, customer relations, and development. In total, 36 formal and many informal interviews were conducted with employees of Sigma, including senior executives, product and technology managers, account managers, operations managers, infrastructure managers, sales executives, pre-sales engineers, service support executives, software developers, and developers. These interviews helped us understand, among other things, the various activities and mechanisms for managing uncertainty in providing the SigmaCloud platform.

The first author also signed up for the "free trial" user account and a "developer" account, which allowed him to attend multiple Sigma-related events as a participant observer including customer and developer conferences hosted by Sigma, user group meetings, and developer group meetings. These events highlighted various issues, tensions, and questions pertaining to uncertainties - some widely known and others simmering beneath the surface - being experienced by Sigma customers. Detailed field notes of the uncertainties and related concerns that emerged at these events were taken, including the informal discussions that happened before and after these events. The first author was also part of user mailing lists and discussion groups that helped him observe and document internal discussions happening within the customer community.

Interviews were also conducted with 24 senior executives and IT-related decision makers from

11

companies who were Sigma customers. These interviews helped us examine the various uncertainties and related challenges experienced during these customers' adoption decisions and platform deployments. We selected two of these customer companies - Energy Corp and CommHousing -for more in-depth study. Both of them were decommissioning their existing on-premise packaged software and deploying SigmaCloud across their organizations, allowing us to follow deployment processes over time. In addition, we felt that examining organizations of different sizes and structures would help us identify broad categories and dimensions of the uncertainties faced in adopting, deploying, and using the SigmaCloud platform.

Energy Corp is a conglomerate and a specialist in energy management, with over 100,000 employees and operations in nearly 100 countries. The company designs and manufactures electrical products, such as circuit breakers, meters, switchboards, transformers, building management systems, and more. CommHousing is a mid-sized company with around 500 employees and over 1,000 partners and is in the

(11)

business of providing affordable housing to communities as well as lending funds and equity to partners for building and managing housing properties. Across these two companies, we conducted formal interviews (28 at Energy Corp and 26 at CommHousing) with senior-level executives, procurement managers, and budgetary decision makers as well as with mid-level managers and engineers involved in project delivery and implementation. These interviews allowed us to understand the rationale behind the adoption of the SigmaCloud platform, and the uncertainties experienced during the procurement and implementation process. We were also able to observe and explore the accounts, justifications, and skepticisms about SigmaCloud (and cloud computing) that circulated within these customer organizations. In total, we conducted 114 interviews, performed around 370+ hours of observation, and collected 918 documents and 2500+ forum messages. All formal interviews lasted between 60 and 100 minutes, and most were recorded and transcribed. We also viewed and analyzed 83 online videos that included live product demos, product advertisements, conference presentations, and interactive Q&A sessions among Sigma, its customers, and industry analysts. These multiple sources of data enabled us to triangulate (Jick, 1979) and understand the phenomenon from different vantage points.

Data Analysis

Data collection and analysis unfolded in an iterative manner (Strauss and Corbin 1997) over four phases. In the first phase, we focused on understanding how platform services that are delivered "at a distance" to thousands of customers are provided and governed by Sigma, what challenges emerge in the process, and how Sigma manages those challenges. We used constant comparative method (Glaser 1965) to analyze the data. Specifically, we followed Charmaz's (2006) approach to data coding of our interview transcripts, field notes, and archival data. We first did "initial coding" to uncover and understand the various activities undertaken by Sigma to deliver their platform "at a distance" to a heterogeneous and distributed set of customers. We also coded for the different categories of concerns raised by customers, prospects, incumbents, industry analysts, and technology journalists. At this step, responses were coded on the basis of "in vivo" codes - phrases and terms offered by the informants. As new observations emerged, we revised the codes and categories to identify several important themes. In particular, we found actors from Sigma repeatedly referring to the uncertainties they face in providing the platform and how they actively deal with these. This prompted us to focus our data collection efforts on how uncertainties are managed by the provider of platform services, and with what implications.

In the second phase, as new themes and puzzles emerged based on previous analysis, missing pieces of information became apparent. This lead us to further focused data collection and analysis. For example, this phase highlighted the importance of the detailed work that goes into safeguarding the platform against uncertainties and keeping it "up and running." We also repeatedly encountered communication about "trust" and realized its prominence within this context. We consequently focused our data collection efforts

(12)

on identifying the specific activities involved in maintaining the operations of the platform, as well as understanding how discussions of trust were articulated and communicated by Sigma.

In the third phase, we did within-case analysis and wrote detailed "descriptive" case histories of Sigma as well as the two customer organizations who deployed, configured, and customized SigmaCloud for their business needs. When writing these case histories, we focused on the uncertainties - including issues and unforeseen challenges that were encountered by the organizations. The individual cases ranged from 25 to 40 pages in length. We then conducted cross-case analysis to identify variations and similarities in themes observed across the two customer organizations.

In the fourth phase, we did "theoretical coding" to strengthen the emerging findings, organize them into different activities, categorize those activities into thematic buckets, and then render those activities that were ongoing and recurrent into a set of mechanisms related to manage uncertainty in platform services. At this stage, we also engaged with relevant literature, particularly studies of platform design (e.g., Bowker et al. 2010, Meyer and Lehnerd 1997) as well as trust and accountability (e.g., Ammeter et al. 2004, Bachmann and Inkpen 2011), to understand and theorize the themes from the data analysis. While the existing literature was useful in explaining some of our observations, it offered fewer insights into the specific ways through which Sigma managed the uncertainties it faced. This led us to explore more deeply the constitutive role played by trust rhetoric, trust dashboards, data models and architecture, and usage analytics/proprietary algorithms for mining "big data" in the management of uncertainty. This iterative process culminated with the final step of organizing the findings around themes and concepts, with links back to the extant literature. We elaborate our findings in the section below.

Mechanisms of Managing Uncertainty in Platform Services

Our findings identified multiple uncertainties associated with online providing of platform services, and these were manifest as concerns about the platform (its privacy, flexibility, security, capacity, responsiveness, and innovativeness), and concerns about the platform provider (the firm's trustworthiness and credibility). Table 2 provides descriptions and examples of these concerns.

Insert Table 2 here

-We found that Sigma addressed these multiple concerns that constitute uncertainties by managing them through five specific mechanisms - architecting boundaries, enforcing safeguards, segmenting customers, producing trust rhetoric, and articulating trust indicators. Table 3 offers supporting evidence for these

mechanisms. After discussing each mechanism in tum, we consider the outcomes of these mechanisms for the management of uncertainty.

(13)

-Architecting Boundaries

An important source of uncertainty that Sigma faced in providing its platform services was managing the privacy of customer data. Since all customers' data and applications are located in the same shared servers, Sigma had to ensure that one customer could not access the data of another customer. A second source of uncertainty that Sigma faced was managing customer flexibility without undermining the performance of the platform. On the one hand, Sigma wanted to give its customers a flexible and customizable user experience that allowed them to adapt the applications and services (e.g., change the workflow, interface, and data structures) so as to better address their business needs. On the other hand, as the platform's codebase and architecture were common and shared by all customers, Sigma had to ensure that customizations done by an individual customer did not affect other customers or the overall performance of the platform.

One way such uncertainties can be managed is through formal contracts, where usage and customization guidelines are clearly articulated, agreed, and signed-off with the customers. But such contracts are often incomplete and difficult to monitor and enforce. Instead, Sigma chose an alternative approach that utilized software code and architecture (rather than contracts) to delimit sections within the platform. Boundaries between one customer's data and that of another as well as boundaries between platform code and customer applications were demarcated "by design" and built into the platform's architecture and associated codebase.

The mechanism of architecting boundaries thus delimited customers within the platform and ensured customer privacy and flexibility. It was materialized through the SigmaCloud platform's design and operation, specifically through what Sigma termed a "multi-tenant" architecture that virtually delineates the boundaries between customers ("the tenants") while physically keeping them together within the same server space and data center. Customers subscribe annually to a "tenancy" within Sigma's platform, an arrangement akin to renting a room in an apartment building where many tenants share the building's common facilities but have walls and doors that give them privacy. While individual customer data and applications reside on a shared server space, these operate within their own application space in a layer that is virtually (but not physically) separated from other customer data and applications. The enactment of this architecture (materialized through complex software code) - also referred as the multi-tenant architecture -enables the data and applications of one customer to remain insulated from that of other customers. As one Sigma executive described:

We take a very pure approach and take special pride in the multi-tenancy [architecture] environment. That means we only have one version [of the code and data model] of our system, and every single customer -whether they're a single user in Japan, a 100 user company in Italy or India, or a 10,000 user company in North America -are all running on the exact same version [of our system] and the exact same infrastructure. Multi-tenancy gives us the advantage that our developers can focus on upgrades without worrying if a customer has to adapt from an earlier version to the new one. The customer gets

(14)

upgrades that are seamless... Also, in this way the customer data - and also their applications and the customizations they make to those applications -are completely isolated from other customer data and applications... So we completely secure it through this way. [Interview]

The multi-tenant architecture also allows customers to make changes and customizations without affecting other customer applications or the core platform code. This is made possible through the operation of metadata that describes how customers' data are structured and how their applications work in practice. This approach enabled Sigma to materially enact the boundaries between one customer and another, as well as between the customer and the platform. This in turn helped Sigma to manage the uncertainties related to privacy and flexibility, while at the same time making the maintenance and upgrading of the platform easier. As a senior executive at Sigma noted:

The delineation of these boundaries make it possible to independently update the system kernel, modify the core application, or customize tenant-specific components with no risk of one affecting the other customer instances. [Interview]

The mechanism of architecting boundaries ensured that one customer could not access the data of another customer, while at the same time availing them the flexibility to make the needed customizations that fit their business needs.

Enforcing Safeguards

Another set of uncertainties that Sigma faced was related to managing its security and capacity. Unforeseen events (e.g., natural events such as earthquakes or floods, phishing and denial-of-service attacks from external hackers) could compromise the security of the SigmaCloud platform. Sigma thus wanted to ensure that the platform was fault-tolerant and adequately secured. Additionally, Sigma needed to make sure that one customer did not monopolize the platform's shared resources (such as memory and processing capacity) that could affect other customers, and degrade the capacity (including throughput and downtime) of the entire platform.

Sigma's mechanism of enforcing safeguards ensured the platform's security and capacity through a number of proactive measures. First, Sigma formulated elaborate security protocols that were documented in handbooks and guidelines distributed throughout the organization, and enacted in software code during all phases of the platform's development. These include procedures for threat assessments on high-risk features, use of secure coding patterns to assess vulnerabilities, adopting static code analysis tools to identify security flaws, and use of Sigma's internal staff as well as independent security consultants, in conjunction with scanners and proprietary tools, to identify potential security issues during software release. Second, Sigma employed a "red team" - a team of internal hackers to identify potential security threats, viruses, and cyber-attacks that could target the platform. The job of the red team is not just to spot possible threats and take measures to prevent them from happening, but also to actively try and create scenarios where such threats and attacks are imminent. This includes mock drills to physically break into the data

(15)

centers, hacking into the codebase of the SigmaCloud platform, initiating denial-of-service attacks, and more. As an Operations manager described:

Another great thing we have got that I love about Sigma -we have a team called the red team... what they get to do is to break into Sigma. It's actually theirjob to think about how to get into Sigma's network and they can literally do anything they want, whether be it from a network perspective, whether it be actually breaking into a physical building and figuring out how to get access... If they ever find anything, we prioritize fixing those types of issues. [Conference Presentation]

Third, in order to manage problems such as data losses that might arise during such events as floods, hurricanes, earthquakes, and power blackouts, Sigma formulated and enacted detailed "disaster plans" for the data centers. These plans were materialized in various forms such as guidelines, handbooks, and contracts with third-party data center providers. As part of disaster planning, a strategy was implemented to manage data recovery, where frequent automated backups of the customer data would be made, and done redundantly so as to ensure multiple copies of the data were saved at multiple data centers. This would allow customers to recover any data that might be lost due to some event or error. As a senior Technology manager at Sigma noted:

So how many times do we save the data? It's six times - that's a lot! So, one of the reasons that is expensive for us to save the data is that we store it six times because we want to make sure that it's there when you really need it, it is there. So we are incredibly redundant. [Conference Q&A session]

Fourth, Sigma runs automated test scripts during every system update and bug fix - however minor -to ensure that these changes do not affect the security and capacity of the platform. The test scripts - also

called "hammers" - are materialized as batch programs that include testing and quality assurance toolkits. These programs run 200,000 different scenarios and approximately 60 million tests to ensure backward compatibility of the platform and consistent service levels.

Fifth, Sigma enforced restrictions that dictated how customers could and could not use the platform. Some of those restrictions were materialized in the end-user license agreement. Below is an example of one such restriction concerning the use of content not provided by Sigma:

Removal of Content and Non-Sigma.com Applications. If We [Sigma] are required by a licensor to remove Content, or receive information that Content provided to You may violate applicable law or third-party rights, We may so notify You [Customer] and in such event You will promptly remove such Content from Your systems. If We receive information that a Non-Sigma Application hosted on a Service by You may violate Our External-Facing Services or applicable law or third-party rights, We may so notify You and in such event You will promptly disable such Non- Sigma Application or modify the Non- Sigma Application to resolve the potential violation. If You do not take required action in accordance with the above, We may disable the applicable Content, Service and/or

Non-Sigma Application until the potential violation is resolved.

Other restrictions on customers were enforced "by design" through what Sigma refers to as "governance limits" that are aimed at restricting heavy usage of the platform by any one customer. These specify the number of API [Application Programming Interface] calls that can be made within a 60-second period, the

(16)

number of call-outs made to external programs, and the number of custom objects that can be created for a single application. Governance limits are materialized as programmatic rules within the platform and automatically enforced, so that heavy or rogue usage of the platform by a particular set of customers does not impact other customers and the capacity of the platform writ large. As a manager in Customer Engineering described:

... Improper or heavy usage by customers is always a problem for us. Sometimes, this happens by mistake. For example, you [customer] write infinite loops, they can take up large amounts of memory. Other times, it is intentional. We are trying to catch all these things with governance limits... that lets us automatically restrict the level of usage. Say for example, number of API calls or number of requests a custom application can make within a pre-specified period... This really helps us in keeping up the quality and performance of the platform. [Interview]

Thus, the mechanism of enforcing safeguards enabled Sigma to actively ensure the platform's security and capacity.

Segmenting Customers

As the number of customers grew, Sigma found it difficult to attend to the demands of its diverse and distributed customer base. This generated a number of uncertainties for Sigma concerning the platform's responsiveness to customer issues and innovativeness. Assessing the needs and expectations of a diverse and distributed customer base using traditional methods alone (such as market research, focus groups, and customer surveys) became increasingly difficult. As a consequence, Sigma was unsure about which features and functionalities should be prioritized, and which new toolkits should be developed in new platform releases. Sigma addressed these challenges by using the data mining capabilities of its platform to algorithmically segment customers into various categories based on usage. As the platform is cloud-based, the actions that customers perform through the platform can be tracked by Sigma. Login histories and patterns of use by customers, including frequency of use, number of objects created, amount of data stored, use of tools like sales forecasting, and many others, were stored, analyzed, and compared. This mechanism of segmenting customers is materialized through the advanced analytics and data mining algorithms that track customer usage on the platform through multiple indicators such as geography (region), usage ("very high," "high," etc.), usage type ("transactional," "interactional," etc.), and expertise ("novice," "explorer," "dormant," etc.)

You just see the number. That tells you a lot... [You know] that "he [customer] doesn't trust the system and he is not going to use it"... So give the users something new, something that drives the lust for using this new system.. .And this approach has been so far extremely effective to us. That's how we get a sense of what the customer's gripe with the platform are. [Interview]

These category statistics are then used to segment individual customer organizations into "account types," including "red accounts" for customers with a number of platform-related issues that are less likely to renew their subscription, "green accounts" for customers with no visible issues and most-likely to

(17)

continue with their subscription, and "purple accounts" for customers with low usage metrics that might not renew their subscription. Sigma used these statistics to formulate updates to the platform that responded to customer issues. Sigma's CEO described the process and the result as follows:

We can see if the users are logging on to the Sigma application... We know that if a customer is not logging on, he or she is not achieving success and will therefore almost certainly leave us at the end of contract. Our customer service team visits these customers, finds the problems, and fixes them for free. [Archival data]

Sigma also used the customer segment statistics to make decisions about innovation - in particular, what to include in new platform releases so as to increase the likelihood of customer retention as well as attract new customers. The mechanism of customer segmentation provided Sigma with information about what features and functionalities were being used/not used by customers, and this helped to prioritize development plans in the platform functionality roadmap. In particular, it helped Sigma decide what new functionalities to add, adapt, or retire from new platform releases, and what additional resources to upgrade or reallocate. A senior executive from Sigma remarked:

The first is how do you market one-to-one with your customers? How do you really understand your customers at a level of depth? How do you collect data that's meaningful? How do you use it in a respectful, relevant way? ... It's about understanding your customers, but then using that data in a way that delivers value. And value is highly personalized, highly relevant communications and experiences.

[Conference Presentation]

This mechanism of segmenting customers enabled Sigma to not only respond effectively to the issues faced by customers but also helped them to sense the demand of the customers, therefore letting them innovate through prioritizing their future platform functionalities.

Producing Trust Rhetoric

While the above three mechanisms helped Sigma in managing its own uncertainties associated with running, maintaining and updating its platform, there were also customer uncertainties associated with the trustworthiness of the platform provider. Customers required ongoing reassurance about putting their sensitive sales- and client-related data in servers and data centers controlled by Sigma. They were concerned about sharing server space with other companies, uncertain about cloud computing as a service deliver model, and hesitant about using an online platform to handle their critical transactions. As a senior IT executive from the medical devices industry remarked:

Well, this is all good, but how the heck would I know that no one is snooping around my data? And I am also extremely uncomfortable with the idea that my client data will reside on the same server as my competitor, and even with some goddamn mom-and-pop shop owner... How could I trust them [Sigma] with all my data and customer contact info? Things could happen, you know, and I just want to be sure. [Interview]

Similar concerns emerged from executives across different industry sectors. Sigma did not initially react to these concerns and focused more on improving the performance metrics of the platform (e.g., capacity,

(18)

response time, security levels). Sigma engineers and system architects believed that customer concerns were primarily related to security, privacy, and performance, and thus could be taken care of "by design" through the platform architecture. However, Sigma came to understand the customer concerns as uncertainties about the trustworthiness of Sigma, its platform, and cloud computing more generally. As an Engineering manager at Sigma reflected:

I mean, most customers, we don't really communicate a heck of a lot [with them]. Most customers are just buying something. So the real issue I think is trust. ... They're trusting us with their data, and they're trusting us to run them in our servers. And so, we needed to prove that, regardless of whether we had single-tenant architectures or multi-tenant architectures or hybrid architectures, or whatever it was - that we have their trust. So I think trust is the essence of the cloud question. [Interview]

As a response to these uncertainties over trustworthiness, Sigma took active steps toward articulating trust as its "number one value." In particular, the company inscribed the notion of trust as the centerpiece of its product positioning strategy and messaging. Its rhetoric around Trust (always capitalized) was materialized in marketing materials, banner advertisements, product release announcements, demo videos, sales pitches, and annual reports; for example, they used slogans such as "Cloud Computing is Trust-based Computing" and "SigmaCloud: Your Trusted Cloud Computing Platform." In addition, Sigma developed white papers on trust and cloud computing, while also appointing a "Chief Trust Officer" to be responsible for monitoring customer issues around trust, and inculcating trust as a foundational value within the company. This is evident in a senior executive's remarks during a public talk:

When I think about my priorities, I always start with Trust. That's always number one for us.. .We really want to prioritize Trust... I wrote that to all the CIOs I met with at the two enterprise counsels and I wrote my priorities, Trust was first... I am spending a lot of time in that area. I will always spend a lot of time in that area. [Conference Presentation]

Sigma continually emphasizes trust as a core value and guiding principle in its stakeholder and product release events. For example, in describing a new product offering, Sigma noted that earning customers' trust was paramount in ensuring customer loyalty. The Chief Trust Officer often gets involved in many of the sales meetings with prospects. As a Sales executive reflected:

There's a variety of people that we use in the organization to help [the sales] process. Our Chief Trust Officer, for example is often used in the sales process. ... And I think it's important for many, they start to understand not all clouds are created equal, and some really focus on things like Trust ... And you know, occasionally you'll get the really paranoid ones from the financial services industry... But in those cases, having someone like [the Chief Trust Officer] is super helpful. [Interview transcript] Sigma's emphasis on trust was ongoing. Even in its most recent marketing pamphlets, product announcements, and customer events, Sigma stressed trust as core to its identity. Furthermore, Sigma's trust rhetoric is not limited to external events but is also materialized in internal sales training programs and expressed in sales pitches and proposals. Sigma's trust rhetoric was also broadcast during the "events" hosted by Sigma. Indeed, events are considered to be of strategic, not just tactical, importance at Sigma, and range from monthly city roadshows to quarterly mini-conferences and culminating in the annual

(19)

mega-event (called CloudConf). This annual mega-event caters to thousands of attendees (customers, prospects, developers, system integrators, consultants, and Sigma employees) and features IT executives and government leaders as keynote speakers. Through its mechanism of producing a trust rhetoric, Sigma was actively and ongoingly attempting to assuage customer concerns about its trustworthiness as a platform provider.

Articulating Trust Indicators

While the trust rhetoric was helpful in managing some uncertainties, a number of skeptical customers and prospects continued to question whether Sigma was "walking the talk." They required further assurance of the credibility of Sigma's internal processes and governance arrangements. For instance, one prospect raised the following question in a conference session: "How would I know that my data would be secure in your servers that are in some remote data centers?" Such demands were exacerbated over time, especially after SigmaCloud experienced a major, multi-hour service outage that prevented customers from accessing their data during a critical pre-holiday period. A technology journalist writing for a popular online magazine raised some questions about the reliability of Sigma's services. In response, Sigma re-framed the concerns related to performance and lack of SLAs (that it could not effectively control) in terms of concerns around security (that it could effectively control), and positioned them in contrast to the status quo (i.e., the frequent service interruptions encountered by customers' in-house software systems). A senior Sigma executive responded to the journalist's questions in a public forum:

Do you think the servers in your office are more secure than ours just because they are inside a locked room? Just because it is within your premises doesn't mean that it is tough to hack into it. Plus securing servers is not core to your business. We spend more money in securing our servers and making them fail-proof because the downside of not doing it is way too high for us - that is CORE to our business. ... We believe that our solution is a lot more reliable than the stuff customers are running even inside their own companies. I go in to customer sites and they say, "Gee... lost our whole data center for two days. We had this problem; we have that problem." I mean, we are experts at what we do, and we work hard every day to give our customers the highest level of performance and reliability and scale and trust in us that is possible. [Archival materials]

But another outage a few months later further eroded customers' confidence in Sigma as a platform provider. Disgruntled customers started a website, SigmaWatch.com, to post downtime log files and disseminate counter-narratives about Sigma's service quality, while others started a blog to chronicle the performance issues they faced.

These public counter-rhetorics about SigmaCloud led many customers and prospects to insist that Sigma come up with service level agreements (SLAs) to warrant adequate levels of uptime and performance of the SigmaCloud platform. In addition, they also demanded Sigma specify credits and penalties if the company is not able to honor the levels specified in the SLA. Despite such mounting pressures, Sigma resisted specifying SLAs due to the potentially huge financial costs that it would incur if performance levels

(20)

To manage the challenge of credibly accounting for its commitment to trust, Sigma developed a mechanism for publicly displaying real-time operational statistics (e.g., uptime, downtime, maintenance, access speed) and system status (e.g., phishing attacks, worm attacks, spain issues). Referred to as the "Trust Dashboard," this displayed both live and historical data on the platform's performance, including up-to-the minute information on planned maintenance, and any malicious software and security threats. This dashboard was made available as a public website that anyone, not just the customers, could access.

The Trust Dashboard operates via input data captured from sensors that are attached to servers in Sigma's data centers and from tracking response times of data packets. The dashboard is promoted as an automated display indicating real-time data that does not require human intervention. A senior executive from Sigma motivated it as follows:

We put Trust as the number one priority for the company, right? And there's great site, Trust.sigma.com, which is a totally transparent view into how our systems are running, issues we're having, all that sort of thing, so that customers are never in the dark about what it is that we're doing... [W]e really do put Trust as our number one priority. And that we walk the talk, we don't just talk the talk. [Conference presentation]

In addition to the Trust Dashboard, Sigma obtained external certifications (such as ISO 27002) and opened its facilities and infrastructure to third-party auditors. It also obtained a number of "Trust" seals that are well respected in the technology industry and which authenticate websites (e.g., Verisign, TRUSTe, and AICPA). These seals are uploaded to Sigma's Trust website, as in this one on privacy:

Sigma's Privacy Statement: Sigma has created this privacy statement ("Statement") in order to demonstrate our commitment to customer privacy. Privacy on the Sigma web site (the "Site") is of great importance to us. Because we gather important information from our visitors and customers, we have established this Statement as a means to communicate our information gathering and dissemination practices. We reserve the right to change this Statement and will provide notification of the change at least thirty (30) business days prior to the change taking effect. To be effective, the change must first also be approved by TRUSTe, and will include directions on how users may respond to the change.

Sigma's trust indicators - the Trust Dashboard, Trust Seals, audit reports, and ISO certifications were visibly displayed on Sigma's websites and reiterated in its conferences and events. This accounting further signaled to customers and prospects that Sigma was not only committed to trust rhetorically but actively assuring its credibility in practice. A senior executive from Sigma noted this in a conference:

Our hardware and software infrastructure set new benchmarks for security, reliability, availability, and transparency. We delivered [a few] billion transactions last year. And they are coming faster than ever, at a current average of approximately a quarter of a second. It's all there for the world to see every day on our Trust website... customers always go away feeling very comfortable that we really do put trust as our number one.. .It really is, it's demonstrated in how we think about our systems from a security and trust perspective every day. So, many [customers] get comfortable with that. [Conference Presentation]

(21)

This mechanism of articulating trust indicators, thus, attempted to signal to the customers on Sigma's efforts to "walk the talk" regarding the internal processes and governance arrangements that they proclaimed to

follow.

Effects of the Mechanisms on Customer Organizations

Having examined how Sigma enacted a number of mechanisms to manage the uncertainties, we now turn our attention to how these mechanisms had a consequential effect on the customer organizations we studied (Energy Corp and CommHousing). Both these organizations were de-commissioning their existing on-premise packaged software and looking for alternatives. The IT executives in these organizations were initially skeptical of cloud computing as a service delivery model, and of cloud-based platforms provided by vendors such as Sigma. They were consequently reluctant to put sensitive business data - such as the "master client list" that included details about prospective projects and client contact information - in the cloud. As the CIO of CommHousing reflected:

So when I presented the cloud strategy in late 2010, the board asked me: 'Well, how do we know if this thing works? What is this cloud? What if it evaporates?' These were all real questions... So we had to prove that Sigma could work in this environment and more importantly, that cloud-based technologies were real. We had to first build some prototypes to help prove the viability of cloud-based solutions. [Interview]

As we followed the deployment of SigmaCloud in these two organizations over time, we observed the executives within these companies getting drawn into the trust rhetoric disseminated by Sigma through its sales pitches, marketing proposals, and conference presentations. For example, when they were asked to present the "move-to-SigmaCloud-platform" strategy to their boards, both the CIOs prepared position papers that used Sigma's trust rhetoric as well as the public endorsements offered by existing Sigma customers. Below is an excerpt from the position paper presented by the CIO of CommHousing to its governing council:

SigmaCloud provides a trusted source of information for [our] operations. We propose using SigmaCloud... to implement the foundation of the integrated operations platform. Because SigmaCloud is a true multi-tenant platform, we will be able to leverage part of their entire infrastructure specifically for our corporate needs. We will benefit from the hundreds of millions of dollars of investment that Sigma has made for infrastructure improvements and efficiencies for quality, performance and security. SigmaCloud is also secure, with SAS70, ISO 270001 and SysTrust certifications.... And unlike traditionally built software, our customizations [to SigmaCloud] and integrations never break, even when Sigma upgrades the underlying platform and service. This model enables Sigma to successfully serve many companies of all sizes around the world, including the world's largest enterprises like [names of some existing Sigma customer]. This Cloud Computing model makes running operations as easy as using a website like Facebook, Google, or Amazon.com.

We also observed instances where the CIOs and senior IT executives of these companies used the Sigma trust rhetoric internally with their in-house IT developers and business users, trying to assuage their concerns about the privacy and performance of SigmaCloud. For example, a senior IT manager at EnergyCorp noted the following in response to a question about concerns with cloud computing:

Figure

Table  1.  Data Sources
Table 2.  Concerns over  Uncertainties with  Platform Services
Table 3.  Mechanisms  for Managing  Uncertainty in Platform Services
Table  4.  Outcomes  of the Mechanisms  for Managing  Uncertainties  in Platform  Services
+2

Références

Documents relatifs

Through a de- tailed analysis of the different sources of uncertainties, we have determined that the solar flux and photon and electron impact cross sections are the main sources

Averaged precipitation changes over France from the limited ensemble of GCMs used here are generally consistent with precipitation changes simulated by wider ensembles of CMIP5

Using the proposed definition, the notion of uncertainty has been divided in four classes (figure 1). The so-called established typology of uncertainty has been built in order to

A general principle that can be derived from this study is that future efforts to reduce the delay between the onset of symptoms and the diagnosis of tuberculosis must focus on

Elevation dependency of the winter, summer and annual mean LSM at 30 cm depth (a), air, ground temperature and surface offset (ground minus air temperature) at 10 cm (b),

Regardless of the bug-fix pattern (e.g., If- related, Data structure, etc.), in the majority of the cases, the context of bug-fix is characterized by the presence of function

So the second part of the paper presents the methodology of the Polynomial Chaos Expansion (PCE) with the Harmonic Balance Method in order to estimate evolu- tions of the n ×

o Rougeole : retour dès le 5ème jour suivant le début de l'éruption ; recherche de la source de l'infection et investigation des proches contacts de l'enfant malade [8] ;