 |
|
 |
 |
|
EDUCAUSE Quarterly  |
 |
A Tale of Two CloudsA Tale of Two Clouds
The University of Washington (UW) has embraced "software-as-a-service" (SaaS) cloud-based tools (e-mail, calendaring, document creation and sharing, conferencing, and so on) in a big way, both officially and unofficially. UW's cloud strategy was shaped by four key ideas:
This article tells the story of how and why UW arrived at this dual-provider strategy, what we've learned along the way, and what still needs to be done. Our story combines evolution, adaptation, and a modicum of planning — but it reflects a conviction that this cloud computing thing is actually a big deal, so we'd better try to surf this tsunami or we'll drown.1 The final chapter of this story has not yet been written; this is a snapshot of a work in progress. This article presents the UW cloud-computing narrative in the following sequence:
OriginsOur strategic experiment with cloud computing started tactically, with a relatively simple problem: our aged alumni e-mail system. It became obvious in 2006 that we needed to either significantly upgrade it (especially in terms of disk quotas) or replace it. Microsoft had recently introduced Windows Live Mail @edu, and using the new, "no-cost" Live@edu sounded pretty good to us and to our alumni office. Not only would it get us out of an unfunded business while giving our alumni a better service, it would allow us to get our feet wet with this new cloud thing. So in 2007 serious feasibility investigations began, and subsequently a joint project transitioned our alums from the university's myUW.net service to what had by then become known as Microsoft's Exchange Labs, and later, Outlook Live. Expanding HorizonsMeanwhile, Google had announced Google Apps for Education Edition (GAEE) in 2006. It was their early 2008 Team Edition announcement that really got people's attention, though. University IT staff around the country began debating the merits of such a service, which enabled ad hoc and do-it-yourself institutional collaboration using the university's identity without the advice or consent of central IT organizations. At the same time, one of our senior faculty members asked that GAEE be evaluated for use by students, faculty, and staff — at least in his department. He expected multiple cloud services to become increasingly important, especially those from Google and Microsoft, but Google was ahead on collaborative editing tools. This request launched extensive conversations with Google about contract terms, plus internal conversations about policies and risk management for cloud services. It's one thing to talk about handing off alumni e-mail to a third-party provider; it's an entirely different matter to talk about using one or more cloud service providers for core business functions such as e-mail, calendaring, and collaborative document creation among faculty, staff, and students. Many of those internal policy meetings ended with a tribute to Joni Mitchell's song, "Both Sides Now," and the line "I really don't know clouds at all." Completely coincidentally, the very day that we consummated a GAEE contract with Google, our Student Technology Fee Committee voted to cease funding our existing student e-mail and web publishing systems. The committee's decision provided new urgency for the cloud service initiative. Prior UseInformal interviews revealed that cloud use was already widespread on campus. For example, many faculty used cloud documents for collaboration both internally and externally. Figure 1 depicts some of the cloud services we found already in use in 2009. (Except for Live@edu, all were in use prior to the institutional cloud initiative.) Of particular note was Facebook, which already had more than 60,000 members in its University of Washington group (it's up to 73,000 now!). Another important discovery was that half of our 50,000 students were already forwarding their UW e-mail to an external provider, such as AOL, Hotmail, Gmail, or other services.
Figure 1. Sampling of Cloud Services Used at UW Business DriversAlthough we started our cloud inquiries with a narrow, tactical focus, as their scope broadened, we found it useful to remind ourselves that as a major research university, our mission is discovery and innovation. Our means to discovery is extreme collaboration, globally and at scale. By global, we mean researchers on every continent, including Antarctica. By at scale, we mean collaborations that can range from a few people in one department to several thousand researchers from dozens of institutions. Collaboration is, therefore, the primary business driver for our cloud computing initiative, but not the only one. We considered four business objectives as we discussed our approach to cloud services from an institutional perspective:
Compliance concerns sometimes impede innovation and experimentation. Clearly we had to take compliance seriously, but we also needed to evaluate the risks of cloud services in the context of the status quo — where faculty, staff, and students were already using a wide variety of cloud services, without any institutional contracts or guidelines to back them up. Moreover, to have any hope for widespread use of the approved cloud services (which would have institutional contracts and guidelines for use), we needed to reduce the organizational, cultural, and technical barriers to adoption. Positioning UW for the Cloudy FutureWe faced a key question: How should our institution think about cloud computing in the context of enterprise risk management (especially compliance), individual effectiveness, and institutional efficiency? A top-down prohibition against using services that the faculty, staff, and students all found useful was not plausible at UW. Instead, we needed a realistic framework for guiding usage, negotiating contracts, and planning IT services. The important shift in scope occurred when we started focusing on services for the entire UW population, rather than just alumni or students, and for the entire collaboration experience, rather than just e-mail and calendaring. The objective became comprehensive collaboration tools for everyone. This theme had profound implications on our service planning. For example, if the goal had simply been to get out of the student and alumni e-mail business, there would have been little motivation to work through contracts and integrate cloud services with our own enterprise systems (especially provisioning tools). Since we had for many years provided an e-mail forwarding service that allowed students and alumni to forward their UW e-mail to any destination, we could have simply stopped providing a local mailbox for those constituencies, as some institutions have done. However, maximizing collaboration opportunities between faculty and students meant we needed to develop relationships with cloud service providers that allowed all of our constituencies to work together and to look into integration of our enterprise infrastructure with a full range of cloud collaboration tools. Key QuestionsOur investigation revealed several key strategic questions:
We also identified many local policy questions, such as:
StrategyOur strategic hypothesis is that collaboration is central to the mission of the university (discovery and innovation), and that information technology is central to modern collaboration — especially tools that provide any time, any place, any device access to digital resources and colleagues, such as e-mail, web, instant messaging (IM), conferencing, calendaring, co-editing and co-publishing documents, etc. Our tactical hypothesis is that the cloud collaboration space is where we should focus our effort because:
These are pretty standard reasons for considering cloud computing, but the "easier collaboration" claim is worth elaboration. Faculty report that it is often much easier for them to create a document on a cloud service (say Microsoft's Skydrive or Google Docs) and send the document URL to a colleague than to arrange for an account on a local system (for example, a wiki) with appropriate access privileges for someone in a different unit or institution. Moreover, the paradigm of co-editing a single document rather than shipping copies and comments around via e-mail is rapidly gaining traction. The "better use of scarce IT resources" motivation includes allowing staff to concentrate on high-value, mission-focused opportunities and also to reduce our data center space and power needs, which have become premium resources. Strategic PremisesA series of discussions on cloud computing were held with UW's leadership, including the University Technology Advisory Committee (UTAC, chaired by the provost), and with faculty, administrators, campus computing directors, and risk management, security, and compliance officers. In due course the UTAC endorsed the following strategic premises:
The last premise and its consequences are the essence of this article. However, it is important to emphasize that we do not consider heterogeneity to be inherently good, nor homogeneity to be inherently evil — plenty of organizations live happily in a technology monoculture. In our case, given that the interesting service choices came from two companies who are both important strategic partners of UW, the decision process behind the strategy was straightforward:
For us, two providers is the right answer, at least for long enough to prove or disprove answer number 2. Another institution's mileage might vary, especially if collaboration outside the institutional boundaries is not quite as high a priority as it is for the UW. In truth, there will continue to be dozens of cloud service providers in our environment. For now, we choose to focus on improving integration and interoperability between Google, Microsoft, and our own enterprise systems. Note that saving money by using cloud services (especially the "free" ones) is not a primary driver, although we think we can save money in the long run. Indeed, we understand that we will need to make investments to integrate cloud services with our enterprise identity and access management systems, that end-user support costs will not go away, and that we will need to support both old and new systems for a significant period. Further, whatever cost savings accrue from using high-scale commodity systems, they come at a price in flexibility. Deploying commercial software systems usually includes a debate about the extent to which local business practices and procedures should be modified to match the existing software, versus adapting the software to current business practices. Cloud computing providers may offer fewer options for customization, but they remain part of the fundamental IT "wretched compromise" proposition: ?Low cost ? implies high scale ? implies aggregation ? implies less choice/less control RoadmapThe net result of our deliberations was an approach embracing two primary cloud/online platforms:
Initially, we thought there might be a third distinct platform to integrate: Microsoft Business Productivity Online Suite (BPOS), a for-fee online offering including Exchange, SharePoint, and Office Communications Server that we see as a possible successor for many or most of our on-premises Exchange and SharePoint systems. However, we learned that Microsoft's online service plans include converging capabilities so that in the future it will not be necessary to segregate some of our people on a separate platform just to be able to provide them with enhanced (premium) services. This is good news, as it substantially simplifies the interoperability challenge we face. The general concept is to launch our flotilla of technology platforms into the Straits of Collaboration, navigate the shoals of Delusion Pass, and hope we can hold a tight formation while drifting between the Scylla of authoritarian inflexibility and the Charybdis of infinite complexity and cost. The specific plan is to:
Figure 2 illustrates the playing field as we envision it. During the migration from on-premises to cloud services, we must support a fearsome array of platforms, and we expect the transition interval will take several years. We don't yet know whether the experiment will succeed, where we define success as collaboration across platform and organizational boundaries that is nearly as convenient as collaboration within a given system. Failing that, can we at least achieve peaceful coexistence?
Figure 2. The Playing Field for Collaboration at UW Strategic ConcernsConcerns about cloud computing differ, though not without overlap, depending on constituency: Institutional view:
User view:
When evaluating institutional (enterprise) risk, there are several points to consider:
In addition to negotiating suitable contract language around FERPA and other compliance concerns, we also revised our acceptable use guidelines to clarify what kinds of data should or should not be allowed onto the cloud services. However, we generally viewed cloud services from contractual partners as an extension of our own local services and applied the same usage guidelines. Moreover, we realized that data protection policies should be defined to cover all storage scenarios (including thumb drives, laptops, and home computers) and not just cloud services. From the user perspective, reliability, privacy, security, and utility are all obvious. Therefore, let's now focus on the simplicity goal, especially since our dual-provider approach would seem to fly in the face of that objective. RationaleA frequently asked question is whether our dual-provider/platform strategy is fraught with unnecessary central IT cost and confusion for our users. The real question is whether a viable alternative exists in our environment. Complexity that gets in the way of collaboration is the enemy. Examples might include coping with lots of different accounts and passwords, confronting incompatibilities between systems, or something as simple as an extra and unnecessary mouse click. It doesn't take much to inhibit collaboration. One way to mitigate complexity is to avoid it by having a single system or a single collaboration platform. We claim that in diverse and complex collaborations, one size does not fit all, and therefore homogeneity is not an option. As the number of collaborators (and their institutions) increases, the plausibility of everyone using a single system diminishes; on the other hand, the complexity of the collaboration usually goes up as the number of users goes up, each requiring credentials for potentially many different systems. How Many Platforms?Like many other research universities, our culture is aggressively decentralized, with diffuse authority. It might best be modeled as a federation of independent business units. These cultural parameters have obvious implications for technology, especially regarding tensions between institutional efficiency and individual effectiveness. We seek both, but favor the latter, sometimes using the phrase "single-digit homogeneity" to emphasize that a top-down single technology choice won't happen here. Heterogeneity always costs more than you think it will, but in our environment, one size truly does not fit all. We feel lucky when one size fits more than one, especially with researchers who are more likely to be collaborating with colleagues at other institutions than UW colleagues. Some participate in worldwide virtual organizations that might use a dozen different collaboration platforms. The university is still working through policy issues such as whether a given service is mandated, supported, allowed, or discouraged for employees in a given context (the two main ones being "administration" and "faculty," with "confidential information" being a third). From a central IT organization perspective, however, we'd prefer to be known as enablers rather than blockers. This perspective often leads to more technology diversity than would result from a more top-down, authoritarian approach. Homogeneity: Imperative or Illusion?If it were possible to either attract or mandate everyone to use a single platform, there would be some obvious and significant advantages but also some corollary disadvantages. Arguments for a single platform:
Arguments against a single platform:
Arguments for why a single collaboration platform at UW is unlikely and/or infeasible, in spite of the advantages cited above:
Given the lack of consensus about which system is "best" and the volatility of that "best" descriptor, instituting a single-platform policy would require a strong top-down mandate, which is counter to the decentralized and diffuse authority culture of this (and most) research universities. Arguments for why users will have a hard time unless a single system is chosen:
Note that these two arguments occur even in an institution using a single platform whenever collaboration occurs with individuals outside that monoculture. In the end, we chose to proceed with the dual-provider strategy and work hard to reduce the collaboration friction among systems. An ambitious experiment, yes, but a single platform was deemed untenable both practically and politically. Moreover, there must be room for additional diversity over time, recognizing the growing set of collaboration tools important across UW, from Facebook to Drupal. This space continues to evolve rapidly, and we need to be agile in responding to new opportunities and needs. Interoperability standards mitigate (some of) the collaboration friction between disparate systems. They have worked stunningly well for e-mail and pretty well for document sharing. Calendaring and scheduling are the exceptions because the standards haven't fully evolved or been embraced yet. With respect to document sharing, information consumers can be relatively agnostic about what kind of platform information is stored on, as long as they do not encounter inconvenient access control barriers. For example, SharePoint and Google Docs can coexist, and where federated SSO is available, moving between them should be relatively painless. From an authoring perspective, every system in use has training and support costs associated with it, so an institutional efficiency argument still applies that says "fewer is better." Authoring and publishing tools such as SharePoint and Google Docs (as well as Drupal, etc.) will coexist in our research universe no matter what we say or wish, so we might as well acknowledge and embrace that — but we should also encourage community support around two or three platforms. At least we can strive for "single-digit homogeneity" in the docs and web publishing part of collaboration. Plan B?Is there a Plan B if we fail to mitigate the collaboration friction among the chosen systems? It is likely that failure to achieve a reasonable level of interoperability would result in pressure to enforce silos of homogeneity, with less opportunity for individual choice of preferred tools. Affinity groups will often (naturally or by fiat) coalesce around a single tool set, but there are organizational costs if this happens without consensus within the group, much less across different affinity groups. Therefore, we have reason to believe that "integration via interoperability" has merit, and we have plenty of motivation to achieve it. ObstaclesCollaboration barriers (friction) include:
Interoperability ScenariosSuppose we have a small team of three collaborators, one from a department using a traditional Outlook/Exchange environment (or BPOS), a second who favors Thunderbird/Sunbird client applications in a department or institution using Live@edu, and a third who uses a Mac, Safari, and Google. Common tasks for the team would include:
Some of the obstacles to collaboration in this scenario include:
Multiple Accounts and NamespacesOne important goal is to enable anyone receiving an e-mail invitation to collaborate to simply click on the included URL and have it work — regardless of the host platform. As one example, consider a researcher who logs into Microsoft Skydrive or Google Docs and creates a shared folder. She invites others to access that folder by specifying their e-mail addresses. Collaborators will receive an e-mail with a URL pointing to the shared folder. E-mail addresses are the basic user identifier in these cloud systems, and everyone has (at least) one, so what could possibly go wrong? Alas, many things:
There are two worrisome consequences to these kinds of collaboration barriers. First, the annoyance of dealing with account provisioning and access control might inhibit collaboration from taking place at all, or second, it might encourage collaborators to remove access controls altogether, which makes it really easy to share documents but complicates protecting information or maintaining the integrity and provenance of research results. Some cloud services (such as Skydrive and Zoho) dynamically provision an account for a user upon first access. Note that these service-specific accounts are "behind the scenes" data structures, distinct from one's basic authentication identity and credentials. Other services (such as Outlook Live and Google Docs) require provisioning an account prior to first use. Even in the dynamic creation case, there must be some notion of an eligibility list. In cases where an account must exist before first use, this can become an obstacle to collaboration, depending on how simple or complicated that step might be for the user. In fact, the concern over whether colleagues already have accounts on a given system might prevent someone from even trying to use one of these platforms, often reverting to sending documents to colleagues via e-mail. Despite concerns about pre-provisioning accounts, doing so might mitigate a potentially significant obstacle to collaboration. Evaluation of these provisioning tradeoffs in our cloud program is ongoing. Another namespace problem for UW concerns differing forms of e-mail address, such as user@uw.edu versus user@washington.edu. Both are completely valid, equivalent, and interchangeable on our systems, but represent completely different users in the cloud services. That is, the domains are not linked as aliases, so the cloud service does not know that both addresses refer to the same person. This can lead to frustration when sharing documents. Most schools have a single primary domain for e-mail, but the same problem can occur when departments offer a local e-mail address such as user@physics.washington.edu that is an alias for user@washington.edu. In that case, a document-sharing invitation sent to the departmental form of the address will prompt the recipient to log in to the cloud service using the departmental domain, which will fail (unless the department operates their own domain in the cloud service). We are still trying to figure out the best way to mitigate the confusion this could cause. Group ManagementTypically, on-premises collaboration tools have been integrated with enterprise identity and group management systems. For example, a faculty member can create an e-mail list for a class by referring to the class identifier rather than enumerating the e-mail addresses of every member of the class. Similarly, departmental rosters and ad hoc groups can be extremely useful in facilitating collaborations. The new cloud-based services will not be nearly as useful or attractive unless they offer the same kind of group management integration. This work is a high priority for our cloud computing program. Federated Identity/Access ManagementThe more collaboration platforms you have, on-premises or external/cloud, the more you really, really want federated access management, including SSO authentication. If scholars expect to use multiple cloud collaboration platforms, we need to stop the multiple-account madness and work with cloud service providers to make federation a reality. Our preferred technology in this space is Shibboleth, an implementation of SAML and other protocols, used in the InCommon trust federation. SAML is already supported by Google and will soon be an option for accessing Microsoft's Live@edu offerings (in addition to WS-Federation technology). Many cloud services provide a simplified user experience via SSO and federated identity management. For example, Zoho allows access via Yahoo or Google credentials, and Digg allows access via Facebook credentials. In addition, the eduroam wireless roaming service, which provides network access to visiting scholars via their home institution credentials, seems to be gaining momentum in the United States. InCommon is considering supporting eduroam in its service set. One downside of federated access and SSO is that one's local identity management system becomes a critical element in reaching the cloud service, so it must be designed for high availability. A cloud service might be less attractive in a business continuity scenario if a local power or server outage could deny access to the cloud service. Other caveats: the additional elements of federated identity management systems add complexity into the troubleshooting equation, and the fact that SSO might not be uniformly available across all systems can add confusion for users. On balance, however, we see SSO via federated local credentials as a win. The Thick Client ProblemWhen thinking about federated access and SSO to cloud services, an important question is, where do passwords live? For web applications, the cloud service provider need not store passwords, since federation protocols allow use of one's home institution credentials for accessing external services. However, there are still many important non-web applications (so-called "thick clients" and mobile phones, for example), while many federation protocols (such as SAML) were designed only for the web app case. In order to support the large installed base of existing thick clients (such as desktop e-mail and calendaring and IM applications), the cloud service provider has two choices:
Both of these strategies expose user passwords to potential security vulnerabilities on the cloud provider's server, but convenience often trumps security. Microsoft has chosen the option of deleting passwords when a domain is federated; Google maintains passwords on their servers even with federated access enabled. Microsoft's Live@edu team is working to support selected thick clients even when a domain is federated (and no longer holds passwords), but we don't yet have a complete picture of the user impact of this scenario. Google is also pursuing the goal of federated sign-on for thick clients via an approach based on OAuth (which can leverage existing SAML infrastructure), but it requires modification of the clients. Maintaining user passwords on the cloud service provider's servers allows all existing clients to work without changing either the client or server code for each relevant protocol. However, that begs the question of whether the enterprise passwords should be synchronized with the cloud provider password store, left to the user to decide, or forced or encouraged to be different. The argument for the last choice is security: if the cloud service is compromised, the local enterprise passwords are still safe. UW has chosen to strongly encourage users to make these passwords different, but ultimately leaves that decision to each user. CalendaringOne poster child for interoperability problems is calendaring, or more precisely, scheduling. We know that good scheduling functionality across the broadest possible constituency is absolutely crucial for many at UW (especially administrators), although it is not even on the radar for others. It is therefore not surprising that opinions vary on how important it is to have a single calendaring system for the university — or, alternatively, calendar interoperability that works. Ideally we'd like to allow scheduling and access to calendar details (within policy limits and user preference) to work smoothly across platform boundaries. An Outlook/Exchange/Live@edu user should be able to view and schedule someone who uses Google Calendar, and vice versa. There are many nuances here, including delegated authority and scheduling resources such as conference rooms, but that's the general idea. There are some third-party solutions on the market, but many of them assume that all Google users also have Exchange accounts, or that Outlook is constantly running for a given user. At a minimum, we need to have good calendaring and scheduling within various working sets of UW's population, with reasonable workarounds for cross-group scheduling. Absent improved interoperability, the likely outcomes are either a strong gravitational pull to a single system (whichever has critical mass) or "calendar silos" where third-party tools such as Doodle help bridge the gap between units using different calendar systems. ConclusionsSo far we have not seen any reason to doubt or change any of our original strategic premises, but it is still early in our grand interoperability experiment (as our project timeline demonstrates). Nevertheless, we can already share some conclusions, lessons, advice, and open questions. CostsNewsflash: Free services are not free. But you already knew that. Some of the reasons include:
It's tempting to believe that these cloud services are like over-the-air TV, providing self-service access to a desirable "free" capability with no fuss. Some of them really are, but to maximize the utility and convenience of a cloud collaboration platform, the services need to be integrated with enterprise identity and access management systems, especially for SSO and password management, and for access to "group" definitions such as class or e-mail lists. This integration requires development and maintenance work. During 2009 we invested over 3,000 person-hours on our cloud computing program. This included lots of meetings, pilot projects, user surveys, and provisioning integration work for both Google Apps and Microsoft Live@edu. The effort was "funded" by deferring other projects deemed lower priority. So far, impact on the help desk has been nominal. On the plus side, we have now retired the aged alumni e-mail service that started our cloud computing experiment and will soon stop provisioning local e-mail accounts for new students. We expect to transition existing students off of the in-house e-mail infrastructure over the coming year. Ongoing user support is an important area to watch, in terms of both cost and user satisfaction. Support of cloud services by the central IT organization is limited. We provide support related to account activation and changing passwords. For other types of support, we have published a number of frequently asked questions and their answers, as well as providing links to the vendor documentation, including:
For faculty and staff, we anticipate that a higher level of support might be required. GovernanceNotwithstanding UW's decentralized/diffuse authority culture, there are both formal and informal governance mechanisms plus a central IT commitment to campus partnership. Relevant groups include:
In addition, we formed a Cloud Computing Coordinating Committee (C4) to review cloud contract issues and cloud computing policies. This group, chaired by UW's executive director for risk management, included representation from the central IT organization, an academic department, plus the university registrar, chief information security officer, senior director for compliance and procurements, and an assistant attorney general. Representatives from purchasing have also been included as needed. Within the central IT organization, an overall cloud computing program was defined, with individual projects for Live@edu and GAEE (each with the same sponsorship team). As the pilot projects were completed and the services launched, the original projects were wrapped up; ongoing activities are being transitioned to a service management paradigm. Additional projects have been initiated for group integration and student migration activities, plus one to better understand the collaboration barriers inherent in our goal-state architecture. Risk Management and ContractsWhen we began this project, deciding to use cloud services for student e-mail was already well established, with the service provider's responsibilities under FERPA the only big issue being discussed in the community. Having UW employees (faculty, staff, and students working as TAs and RAs) using cloud services for mission-critical functions such as e-mail and document sharing was a different matter. Crucial questions included ownership of the data, how well is it protected, what the storage provider might use it for, our access to our data for e-discovery, and so forth. Volumes have been written about the cloud's safety (especially regarding privacy and security). We concluded that, for UW's intended personal productivity and collaboration uses, it is safe enough. We used an enterprise risk management approach to evaluate institutional risk for different use cases and classes of data. In particular, we looked at risks if our employees continued using consumer cloud services with no institutional contracts but with the addition of acceptable use policies and training, and with tailored contracts. This analysis led to the conclusion that UW's risk profile would be substantially improved by establishing contractual partnerships with key cloud service providers and migrating employees from consumer versions of their preferred cloud service onto UW contracted/sanctioned services. Additional support for this conclusion came from the observation that not all UW data is stored on well-managed systems in secure data centers (as UW's Kerry Kahl noted2). When we first began contract discussions in 2008, we found it useful to prepare an offer sheet, outlining what we hoped to get out of the relationship and what we imagined the cloud provider was looking for. We also developed a template for key contract terms. On the contract front, our attorney general's office did a lot of heavy lifting with both Google and Microsoft. In particular, Assistant AG Bill Nicholson was instrumental in coming up with breakthrough wording to deal with FERPA, which (with enhancements by Steve McDonald at the Rhode Island School of Design) we expect will soon be a standard part of these contracts for educational institutions. We also got agreement on terms that clarify data ownership, restrict what cloud service providers can do with user data, and allow us access to the results of company security audits (such as SAS-70 Type II). As a corollary to the contract work, we also revised our acceptable use guidelines for computing services to include cloud considerations. As previously noted, the primary goal for our cloud program is individual knowledge worker productivity and collaboration, and the solution set is SaaS application providers of cloud-based productivity and collaboration tools. We avoided some risk issues (in the context of this program) because we do not plan to move massive amounts of institutional/enterprise data to the cloud. Before considering cloud solutions for hosting such data (probably using lower-level cloud services, such as storage and computation in the infrastructure-as-a-service category), additional risk management discussions would be in order. PushbackIn September 2009, after completing successful pilot projects with both Google and Microsoft, we launched the new cloud services for students and alumni. Rollout for faculty and staff is about to launch. In addition, the Computer Science and Engineering department elected to operate independent Google Apps and Live@edu domains (separate from the campus-wide domains); they launched for their faculty, staff, and students in fall 2009. The services have been generally well received, but not without some pushback. Some students, many of whom already used "consumer" cloud services for their UW e-mail, questioned the advantage of using the new UW-sanctioned cloud services as compared to simply using personal/consumer accounts from the same companies. At the moment, there isn't much difference (other than the absence of ads in the institutional services), but that answer will change when:
Although we have not yet officially launched the services for faculty and staff (except in the CSE department), we do have a number of early adopters and already know that faculty have concerns about privacy, security, data ownership, and data mining. Many of these concerns are adequately addressed via contract terms that, for example, clearly state that the institution owns its employees' data (like data stored on our local systems). Our cloud computing program thus has provided opportunities to clarify existing policy and practice. For example, some faculty had misconceptions about the privacy of e-mail on our own in-house systems, not realizing that data held on UW servers is subject to the state of Washington's Public Records Act, which requires state agencies to make most of their records (including e-mail) available to the public. Our compliance officials are comfortable with the cloud risk analysis results summarized in Kerry Kahl's article.3 That does not mean, however, that every unit of UW is racing to embrace the cloud. For example, our medical center is taking a cautious wait-and-see approach, and units involved in classified research or export-controlled data appreciate our acceptable use guidelines, which clearly forbid cloud use for certain classes of data. Another area of concern was e-discovery and whether we would have the ability to access the data needed to respond to legal requests. Our contracts included appropriate language to ensure the university had the right to do so, but in some cases technical work was needed on both the cloud provider side and our side to give support staff tools to fulfill most e-discovery requests without provider intervention. In fact, the timing of our rollout to faculty and staff depended in part on resolution of this issue. Sometimes we hear pushback from the cloud provider when we explain our requirements. For example, our need/desire to use "uw.edu" for e-mail, log-in, and collaboration credentials on all relevant Exchange platforms has proved challenging for Microsoft. This domain namespace issue (in particular, the fact that our alumni share the same e-mail namespace as everyone else at UW) was also a primary reason it took longer than expected to get from initial discussions to a workable technical solution for the alumni e-mail replacement project. Yet to be determined is the kind of pushback we will get from users when they really try to collaborate across platforms. For example, will alternate e-mail address forms (equivalent in UW systems) prove insufferably frustrating in the cloud collaboration space? Time will tell. Next StepsOur plans for the coming year include the following steps. Enhancing cloud services:
Retiring on-premises services:
AdviceFirst, we encourage institutions of any size to embrace a risk-management approach to assessing cloud services and to realize that discouraging their use does not make the risk go away. Second, be clear about your objectives and success metrics — improving compliance and collaboration were our primary goals. In our view, multi-provider cloud computing is a (mostly) progressive inevitability. However, UW is a large and complicated creature, and we don't urge others to follow our model. Other institutions with different cultural, technical, or political requirements might reasonably decide to forego our adventures in interoperability and pick a single cloud service provider for the bulk of their needs. We would argue, however, that as collaboration requirements spread beyond the institution, some of the same interoperability problems we chose to tackle will resurface. Before moving to the cloud, ask in-depth questions about how your local architecture and practices match up with those of your service provider(s). Do you want to provision accounts en masse, or on an incremental, self-service basis? Do your alums, students, faculty, and staff share one e-mail namespace, or are they separated into several (such as students.xyz.edu)? Do you have multiple domain name aliases (for example, uw.edu and washington.edu) for e-mail? Do you ever reuse personal identities? What do you want to have happen to accounts when students graduate or employees leave? How important are thick clients and SSO? How important is universal seamless calendaring? What are your e-discovery and HIPAA needs? And so on. Finally, we advise everyone to encourage their service providers to embrace open standards and the concept of "integration via interoperability," both within and across platforms. Open QuestionsHaving made this initial commitment to cloud services, UW still has outstanding questions:
For commentary on these questions, see http://www.uw.edu/staff/gray/papers/cloudquestions.html. So far, we consider our cloud computing program a success, but it is still early. As we find answers to these questions, we look forward to sharing them with the community. As you can see, the UW has fully "embraced the cloud"!
AcknowledgmentsMany thanks to Ed Lazowska, Tom Lewis, Erik Lundberg, Zephyr McLaughlin, and Oren Sreebny for their suggestions on improving this article, as well as their (and many others') essential contributions to the UW cloud-computing program as a whole. Endnotes
© 2010 Terry Gray. The text of this article is licensed under the The text of this article is licensed under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 license.. Bookmark/Search this page with:
|
 |
 |
 |
||
| EDUCAUSE Quarterly authors retain the copyright to their intellectual content, with individual articles licensed under Creative Commons licenses. EQ articles reflect the opinions of the authors and not necessarily those of EDUCAUSE or its members. For more information about EDUCAUSE copyright, please see http://www.educause.edu/copyright | |||
