A Tale of Two Clouds

Key Takeaways

• The University of Washington adopted a dual-provider cloud-computing strategy, focusing initially on software as a service.
• The original project — to replace an obsolete alumni e-mail system — resulted in a cloud solution that soon grew to encompass the entire campus community.
• The policies and contract terms UW developed, focusing on compliance and reducing barriers to collaboration among faculty, staff, and students, provide a solid foundation for additional cloud computing endeavors.

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:

1. Our community is already using and benefiting from a wide variety of cloud-based services, and it would be counterproductive to oppose their use despite the institutional concerns that come with the cloud.
2. The university's risk profile would improve over the status quo by establishing one or more preferred collaboration platforms, backed by contract terms that address institutional risks.
3. We should use the cloud opportunity to encourage collaboration across all sectors of our community (faculty, staff, and students) rather than, say, just using cloud services to get out of the student e-mail business.
4. We should partner with both Microsoft and Google in order to provide the best options to our very diverse population.

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.¹ 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:

• Origins
• Strategy
• Rationale
• Obstacles
• Conclusions

Origins

Our 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 Horizons

Meanwhile, 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 Use

Informal 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 Drivers

Although 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:

• Improve individual and group effectiveness via better collaboration tools
• Improve institutional efficiency via cost avoidance and containment
• Improve institutional risk management via partner contracts
• Enable rather than block innovation and experimentation

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 Future

We 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 Questions

Our investigation revealed several key strategic questions:

• Why cloud services, instead of existing on-premises systems?
• And why not cloud services? (What are the risks and limitations?)
• Why partner with specific vendors, rather than just letting people use consumer services?
• Is a single/homogeneous collaboration platform either feasible or desirable?
• How important is having a single calendaring system for the entire campus?
• Can the collaboration friction between the Google and Microsoft platforms be reduced, and at what cost?
• Should cloud services be tightly integrated with existing enterprise infrastructure?

We also identified many local policy questions, such as:

• What acceptable use, data protection, and other compliance guidelines should be established, including for FERPA, HIPAA, and e-discovery?
• Within compliance guidelines, what latitude do individuals or units have in choosing which tools/services to use?
• For those in the Microsoft camp, who should use the free service versus the premium (for-fee) Exchange/SharePoint options?
• Should cloud service accounts live forever? (Or at least as long as the service exists under the original terms!)
• Should cloud service passwords be the same as or different from enterprise passwords?

Strategy

Our 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:

• It's where our people are going (or already are).
• It allows easier (self-service) collaboration.
• It leverages market agility and technical advances.
• It enables better use of scarce IT resources.

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 Premises

A 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:

• Cloud computing is a big deal.
• UW should encourage it, consistent with compliance obligations.
• Compliance risk is reduced with partner contracts.
• Integrating faculty and staff with students is essential.
• A single-provider strategy will not work for UW.

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:

1. Is consensus possible that one cloud service is best across-the-board??No
2. Are the technical consequences of two cloud service providers acceptable??Yes

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

Roadmap

The net result of our deliberations was an approach embracing two primary cloud/online platforms:

• Google Apps Education Edition (GAEE), with free e-mail, calendaring, docs, sites, etc.
• Microsoft Live@edu, with free Exchange-based e-mail, calendaring, Skydrive, and IM

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:

• Integrate both MS Live@edu and GAEE into our existing enterprise service subscription (provisioning) system.
• Enable single-sign-on (SSO) via our existing Security Assertion Markup Language (SAML)/Shibboleth federation infrastructure. Although Live@edu does not yet support SAML-based federated access, we have partnered with Microsoft to change that.
• Make Live@edu and GAEE generally available, initially to students and alumni, and subsequently to all faculty and staff.
• Integrate these cloud services with enterprise "Groups" infrastructure, so faculty can leverage class lists, etc.
• Evaluate Microsoft BPOS capabilities as we seek a lower-cost successor to our central Exchange/SharePoint installation.
• Enable individual departments to operate independent Live@edu and GAEE domains.
• Transition gradually whenever possible, via soft launch, to reduce help desk impact.

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 Concerns

Concerns about cloud computing differ, though not without overlap, depending on constituency:

Institutional view:

• Operational risk — service or business failures
• Financial risk — surprise support or integration costs
• Compliance risk — failure leads to liability costs and reputation damage

User view:

• Reliability, privacy, security — similar to operational risk
• Utility — functionality
• Simplicity — which requires interoperability

When evaluating institutional (enterprise) risk, there are several points to consider:

• With respect to operational risk, right now individuals have the biggest stake in whether or not a cloud service fails, but that changes as more and more essential functions shift to cloud services. As cloud use for business-critical functions grows, starting with e-mail and calendaring, the institution must take a strong interest in assuring that the service will be there when needed, both on an immediate basis (service interruptions) and on a long-term basis (service termination). For availability, we look to service level agreements (SLAs) to mitigate risk; for long-term control of our "data destiny," we need to think carefully about exit strategies.
• With respect to financial risk, one concern is that a high-touch support model could eliminate any future savings from cloud computing for basic services. Many of the interesting cloud services were designed for an ad-based consumer business model, and those economics don't work without a lot of self-service and community support of end users. If your institution has a culture of providing high levels of support (especially to faculty), that tendency should moderate expectations of cost savings via cloud services.
• With respect to compliance risk, the biggest concern is unauthorized disclosure or contamination of sensitive or confidential information. There must be arrangements to allow compliance with legal requests for data (e-discovery), and in the case of a security incident, it must be understood that low-level forensics on a hard drive to assess whether the breach led to unauthorized disclosure of personally identifiable information or personal health information will not happen — at least not by university staff.

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.

Rationale

A 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:

• Simplicity, with no multiple-account madness and no interoperability issues
• Lower cost than supporting multiple systems

Arguments against a single platform:

• Vendor lock-in
• Competition undermined
• Individual choice hampered
• Greater adverse impact if vendor terminates service
• Inconsistent with faculty needs to collaborate with non-UW colleagues

Arguments for why a single collaboration platform at UW is unlikely and/or infeasible, in spite of the advantages cited above:

• Faculty will want to collaborate with colleagues at other institutions, many of whom use a different platform. For many faculty, collaborating across UW (especially with the administration) is not an important goal; collaboration with students and academics (here and elsewhere) is the priority.
• Faculty might want to collaborate with students wherever those students already have an established presence.
• There is no consensus on which single system would be preferable, with strong partisans on both sides.

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:

• Lack of calendaring interoperability is often cited as the biggest problem with having multiple collaboration platforms.
• Multiple accounts are needed for sharing documents absent federated access and dynamic (or pre-) provisioning of accounts, which can be a significant annoyance.

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.

Obstacles

Collaboration barriers (friction) include:

• Multiple-account madness and provisioning pain
• Namespace confusion
• Lack of interoperability
• Lack of enterprise "groups" integration (such as making class lists available for access control or e-mail lists)

Interoperability Scenarios

Suppose 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:

• Schedule a meeting and/or review calendar entries
• Create a group e-mail list
• Create an access group for sharing docs with additional colleagues
• Co-edit a document
• Participate in e-mail, chat/IM, and video conference interactions

Some of the obstacles to collaboration in this scenario include:

• Discovering the authoritative server(s) for each individual user's information (calendar data, preferred chat service, ID, etc.)
• Access management and account provisioning for each relevant platform
• Navigating multiple namespaces that may overlap or conflict
• Compatibility of data structures (such as document formats) and protocols (such as IMAP or CalDav)

Multiple Accounts and Namespaces

One 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:

• The recipient may not have an account on the target system and might not know how, or be allowed, to get one.
• The invitation might have been sent to a valid e-mail address, but not a valid identifier on the target system.
• The folder owner may have chosen to restrict access to a group or domain, thinking that all recipients belonged to the approved domain and that all recipient e-mail addresses were part of it. (One form of e-mail address to a given person might work; another form might result in failure to access the folder.)
• The valid e-mail address might be a valid identifier in both the sanctioned institutional and consumer services of a collaboration platform, but those two worlds have very different compliance implications.

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 [email protected] versus [email protected]. 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 [email protected] that is an alias for [email protected]. 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 Management

Typically, 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 Management

The 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 Problem

When 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:

• Continue to hold user passwords, just as was necessary without federated access, or
• Build proxy functionality into their servers so that user credentials arriving at the server are used to initiate an authentication transaction back to the enterprise.

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.

Calendaring

One 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.

Conclusions

So 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.

Costs

Newsflash: Free services are not free. But you already knew that. Some of the reasons include:

• You still need a help desk, and during the transition period you'll be supporting old and new systems.
• If you have a high-touch service culture, it might be more difficult to leverage the do-it-yourself support paradigm that underlies many cloud services — especially the free and ad-supported ones. This is a cultural issue on both sides of the help desk.
• If you decide to do a deadline-driven migration rather than a soft launch and gradual migration, extra staff might be required to help users during the transition.
• If you choose to enhance the cloud services by integrating them with enterprise provisioning and identity management systems, there will be development and software support costs. And if you choose NOT to, there will likely be higher user support costs.
• If you are an early adopter (as we have been), expect the service offering to change. Often. In which case, the development costs noted above will increase, and developer morale may decrease. (For one of our cloud services, we are now on our third rewrite of our provisioning code, as the service interface has evolved.)
• Expect to spend time on policy development and governance, and a considerable amount of cultural reseeding. At least in the beginning, expect many meetings.
• We choose to maintain an e-mail forwarding capability in order to offer lifetime e-mail addresses to our constituents, independent of any particular provider or mailbox destination. (Note: forwarding to nonsanctioned services by employees is discouraged.) This requires us to maintain e-mail forwarding, directory, and anti-spam infrastructure. This is not a new cost, but institutions choosing to completely shift their e-mail services to a single cloud provider can avoid them.

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:

• http://www.uw.edu/itconnect/teamwork/cloudfaq.html
• http://www.uw.edu/googleapps
• http://www.uw.edu/windowslive

For faculty and staff, we anticipate that a higher level of support might be required.

Governance

Notwithstanding 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:

• University Technology Advisory Committee
• Faculty Senate (especially the Committee on Educational Technology)
• Board of Deans
• Campus Computing Directors

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 Contracts

When 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 noted²).

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.

Pushback

In 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:

• The services become available for all faculty and staff (in addition to students and alumni), thus permitting broader collaboration.
• Our partnership with Microsoft on SAML-based federation results in SSO for Live@edu services.
• Our enterprise "group management" infrastructure is integrated with the cloud services, enabling easy collaboration using e-mail and department and class membership lists.
• Our teaching and learning tools integrate with the cloud platforms, for example using a mash-up of on-premises and cloud software to replace a locally developed e-portfolio system.

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.³ 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 Steps

Our plans for the coming year include the following steps.

Enhancing cloud services:

• Complete rollout to all faculty and staff
• Integrate group management features
• Pursue deeper integration with teaching and learning tools
• Improve calendar interoperability
• Deploy SSO for Live@edu
• Understand in more depth the barriers to collaboration in a multiplatform environment and work to eliminate or minimize them

Retiring on-premises services:

• Student e-mail services
• Student e-portfolio system
• Central Exchange/SharePoint services (via move to Microsoft BPOS)

Advice

First, 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 Questions

Having made this initial commitment to cloud services, UW still has outstanding questions:

• Will 2010 see progress on interoperability between Exchange and Google Calendar?
• If substantial progress does not happen, how big a problem will that be?
• Will the services evolve so that effective collaboration can occur regardless of which platform hosts the data?
• How well integrated will Microsoft BPOS and Microsoft Live@edu services be?
• What will the uptake trends look like for each service and for different segments of our population?
• What are the tradeoffs of separate deployments for individual departments?
• Does it make sense to pre-provision accounts for all faculty and staff in order to avoid the "stop to create an account" barrier to cross-platform collaboration?
• What fraction of faculty and staff will be adequately served by the free offerings versus premium services (BPOS or add-on capabilities such as Google's Postini, for example)?
• Will we live to regret our dual-provider strategy? Or will we expand it to include additional partners?
• Will thick-client use decline? For those who use thick clients, will support of standard data access protocols (IMAP, XMPP) and authentication protocols be adequate?
• Will help desk costs remain stable, go up, or decline?
• How difficult will it be to retire existing on-premises systems for faculty and staff?
• Will our hypothesis be vindicated that including faculty, staff, and students in these services will increase collaboration among them?
• How should we go about measuring success, and how much should we spend, at what intervals, on such measurements?
• If an exit strategy becomes necessary, how painful will that be?

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"!

Acknowledgments

Many 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.

1. 1. The scope of the initiative described in this article is SaaS cloud-based collaboration tools, but UW is also using infrastructure-as-a-service (IaaS) cloud offerings. For example, we assist scientists in taking advantage of the on-demand scaling and pay-as-you-use pricing of Amazon's infrastructure web services (Elastic Compute Cloud, EC2, and Simple Storage Service, S3) and Microsoft's Azure. We also have departments using web storage services for off-site backup. These other types of cloud services are also growing in importance, but they exceed the scope of this article.
   2. Recommended reading on this topic is a short article by Kerry K. Kahl, UW's Senior Director for Enterprise Risk Management: "Tales from the Front: Computing Forecast: Clouds on the Horizon, with a Chance to Manage your Risks," The Western Association of College and University Business Officers Newsletter, issue 67 (Winter 2010), pp. 10-11.
   3. Ibid.

© 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..