I'm optimistic that there will be progress. At a minimum, I would expect to see bi-directional free/busy information available between GCal and (some subset) of our Exchange platforms. However, a lot depends on how well-integrated MS BPOS and live@edu services will be. The big question is whether a solution is forthcoming that will permit side-by-side calendar details in Outlook, delegate access, and room or resource scheduling --across the platform boundaries.

This depends on local culture and expectations. We'll assume at a minimum that each department has some form of calendaring available. For those who don't tend to schedule meetings with people outside their department, that is enough. For those who do, free/busy interop may be plenty, even though having access to at least a meeting subject name can be very handy when collaborating.

Again I am optimistic that we will be moderately successful on this goal, if we can break the code on SSO to the various MS platforms. Right now a Microsoft online service domain can either be federated via WS-Fed (MS technology), federated via SAML/Shibboleth technology, or unfederated. We need to better understand how that plays out in their multi-tenant, multi-platform scenario.

This is a huge question, and we're working hard with Microsoft to better understand the answer. It could be anything from "perfectly, because the platforms will converge" to "terribly, because of namespace policies that cannot be accommodated with the current technology."

Anyone's guess.

It simplifies collaboration within a department where there is information (e.g. calendar details, default access for documents) that the unit desires to be local, rather than visible university-wide... BUT it is a "not insignificant" barrier to collaboration across the entire university for the same reasons. Perhaps the worse-case scenario is a department that uses a local subdomain for all of their email (e.g. xxx@yyy.uw.edu) but does not have a cloud domain matching yyy.uw.edu. In that case, a document sharing invitation to someone in yyy.uw.edu will fail because the individual will not be able to login to the cloud system using that domain.

Yes. In the case of Google, which maintains passwords for use by thick clients (even when SAML SSO is enabled), these accounts can be provisioned with null or random passwords (re-settable by users if/when desired) in order to reduce risk of hostile account takeover via dictionary attack. When a user is provisioned with a UW netID, they should at the same time be able to specify where they want their email directed, and have accounts provisioned on both Google and MS systems to facilitate document or calendar collaboration.

In my opinion, a very high percentage. But we have no real data on this.

Too soon to tell.

Too soon to tell, but this issue might keep us from federating our live@edu domain due to Microsoft's decision to purge passwords from their servers when a domain is federated.

Too soon to tell.

Probably pretty hard, even if the cloud services are wildly popular. We've already seen cases where staff have migrated to a new system, but want to continue to use the existing IMAP servers for redundancy or archiving. We'll need to watch how the trends evolve and formulate policies accordingly.

This is one of the most important questions we need to answer in order to evaluate the overall strategy. See next question...

User surveys are one key tool. I don't have a strong opinion on how detailed or how frequent such surveys should be. Fortunately, we have experts on such things in our Learning & Scholarly Technologies group.

Another thing to watch is where students choose to direct their UW email. Right now, about 50% forward it to an external consumer email service. If that number continues to increase, it would undermine the premise. A decrease in that number would strengthen the premise. However, there is more to collaboration than preferred email delivery, and there might be a lot of document sharing going on across the sanctioned cloud services even if students continue to forward their email elsewhere. Evaluating the effectiveness of the cloud services in terms of increased collaboration is an area that definitely requires more study.

I'm not too concerned about this. Both Google and Microsoft provide ways to export data, although worst-case, it would be a slow, manual, and individual process. Google, to their great credit, even has a "data liberation" initiative to make it easier to abandon ship.

Another point: one of the potential benefits of our dual-vendor strategy is that if one provider ceases to be viable, there is another one already in place. That doesn't eliminate the data migration issue, but it does provide an interesting contingency scenario.