August 14, 2009
This article is also available as a PDF file for printing.
Within the last year a vast literature has emerged on outsourcing and cloud computing. This memo will not attempt to rewrite that which has already been written and can easily be obtained for more information on the subject. This memo will, however, summarize what cloud computing is, what its relationship to outsourcing is, what areas in the information technology arena are available for outsourcing, and what some of the obvious and not-so-obvious challenges of outsourcing are. It will provide a focused check list on some legal and policy issues to address in contracts between institutions and outsourcing entities and, finally, make two recommendations, one for an internal procedure by which to address these issues and the other for a collaborative approach to some of these challenges from the perspective of higher education.
The concept of outsourcing requires no introduction since it has been a component of strategic direction and/or has functioned as a factor in individual campus’s cost/benefit analysis in areas as diverse as food services, textbook provisioning and bookstores, residence halls, and health and safety services. Even in the information technology area, outsourcing has long maintained a presence, most recently before cloud computing, in network services; in response to a myriad of security and legal issues a number of schools outsourced their residential life networks, for example. With the advent and development of "Web 2.0" and "Cloud Computing," the trend towards outsourcing has accelerated and will continue to accelerate because of intrinsic interdependencies between the outsourcing and the "cloud." Moreover, economic exigencies may be shortening the adoption timetable.
EDUCAUSE defines cloud computing as the “delivery of scalable IT resources over the Internet, as opposed to hosting and operating those resources locally.” Commercial mail services such as Yahoo or Gmail and social networking sites like Facebook are some of the most obvious examples of services “in the cloud,” and electronic mail for students, as well as for faculty and staff, is the most frequently adopted cloud computing service in higher education to date, with currently almost 25% penetration rate for student mail among colleges and universities in the United States. The list of potential services is almost endless and covers virtually every area of information technologies, including those “at the top of the stack” such as course management and administrative systems; those in the middle such as hardware and software provisioning, disaster recovery, back-up, and data storage; and those down at the network level including Internet service and bandwidth.
For a brief primer, please see Appendix A, EDUCAUSE’s 7 Things You Should Know About Cloud Computing.
Some of the "cloud's" most attractive features are the ability to purchase resources on an as-needed basis and to avoid capital costs and internal operation expenses. A low price point and nimble accommodation of both quality and kind of demand also recommends it, as well as contracted upkeep and compliance with regulatory and technological standards. Delivery of those services occurring on and through the network most frequently with commercial, for-profit entities implicates outsourcing. "Greener," flexible, and transparent costs must be balanced against loss of on-site, local expertise; the freedom to collaborate with other information technology shops around the country if not the world; and the loss of control over the services that support the missions of higher education. Some might even argue that the overall dependency that outsourcing creates for higher education on commercial services is inimical to the role that higher education plays in American and global society as a principal source of free inquiry and pure innovation.
At a more granular level, most CIOs currently have concerns regarding information security and privacy, ranking these as the number one risks to emerge from an outsourcing cost/benefit analysis. As vendors recognize the need to provide services that meet or exceed the full spectrum of legal regulation and technical security requirements colleges and universities face, in particular the requirement to protect education records, entities will build those requirements and protections into their services. It is therefore all the more imperative that colleges and universities collaboratively create a consensus around a baseline set of standards to render outsourcing a viable choice and to create competition within the marketplace for those vendors most willing to tailor their services to the specific needs of higher education.
The collective experience of a number of universities that have contracted with Google for email services is an example. Technologists, attorneys, and IT policy personnel first observed that Google reused the same foundational contract for all of the schools with whom it was negotiating and that in early negotiations, Google was resistant to changing contract language. As a number of schools placed more pressure on Google to amend its language, particularly to address FERPA concerns in outsourced faculty and staff mail, Google became more willing to negotiate those terms and assume responsibility to maintain the privacy of those records in the same manner as is required of institutions. Indeed some institutions, including Cornell, insisted that the language regarding FERPA protections also be included in contracts for the sourcing of student mail, although an informal consensus of attorneys who work closely in this area do not believe that institutional liability for FERPA violations lies in student mail. Although a small example, this one with Google may be a positive sign that if and when colleges and universities place clear, consistent expectations on vendors, the market may induce vendors to work productively with our institutions.
Below is a list of the top ten issues that warrant particular attention in outsourced vendor contract negotiations.
Contract should require the entity to maintain all of the legal technical and procedural requirements of all public privacy laws, including but not limited to the Privacy Act of 1974; the Family Education Rights Privacy Act of 1974, amended; the Fair Credit Reporting Act, as amended by the Fair and Accurate Credit Transactions Act of 2003; the Health Insurance Portability Accountability Act of 1996, as amended; the Gramm-Leach-Bliley Act of 1999; and the Payment Card Industry Data Security Standards, most recently updated as of 2008.
To date no federal law requires notification in the event of a breach of personally identifiable information. A majority of state laws do, and interpretations about how and in what ways they apply to other states differ among legal theorists. This uneven and ever-changing landscape makes clear and consistent contractual language difficult to impose. Be that as it may, institutions may decide either to impose those rules found in their home state or to require the entity to adhere to the state with the most rigorous standards of notification and protection. A third approach may be for the institution and the entity to create its own standards for the management of breaches that would include provisions about who reports the matter to whom, the test for a breach and the technical criteria used to do the assessment, and finally which party has responsibility for notifications and follow up, such as credit reporting arrangements. Indeed, such efforts, if done collaboratively among institutions and smartly with the vendor could in fact lead to adoption by the federal government at such time as it will almost inevitably pass legislation.
Allegedly "free" services require the entity to ask the question of "what is in it for the vendor?" For many web vendors, their business model revolves primarily around advertising; marketing plays a supporting role. In order to achieve that goal in a highly competitive environment, vendors must take advantage of the information under their control; for example, user web search terms and the content of stored information in mail or other file folders. Data mining, aggregation, and sale for targeted marketing is a very significant portion of their revenue. It is therefore imperative that an institution representing its users must examine its own culture, law, and traditions in the area of information privacy and be prepared to make clear claims regarding what is and is not acceptable behavior on the part of the vendor.
For example, the current standard Google student mail contracts reveal nothing about what Google does with web search terms. It clearly states that the stored mail will be mined, but anonymized, and that not until the student graduates will it feature advertisements on the site. Some institutions may want to bear down on these issues, for a minimum requiring that if Google does mine search terms, that it do so mechanistically and with anonymizing features. Moreover, most institutions would want assurances up front that no personally identifiable information will ever be aggregated for advertising and marketing purposes while the user still uses the account as a student. For faculty and staff mail services, the institution might want to make that assurance a permanent feature of the agreement. Finally, opt-in and opt-out services might also be offered, for example, on user search terms. The institution would contract explicitly on this point to be sure not only that options exist, but also that clear user education and training materials include information about all of these features and about how a user may optimize the privacy of their communications. Specific points to clarify might include: information about any anonymization techniques that the entity uses to separate information from user identity; whether the entity captures search terms and/or queries; whether the entity does or does not associate those terms and queries with individual users; what the entity does with and how it manages the security of that information; whether it sells the information; how long it maintains records of individual's searches; what other uses it makes of that information; and that the entity promises to permanently purge that information as of a specified date.
The institution should, before entering into contract negotiations, do a cost-benefit analysis of how and in what ways to manage e-discovery concerns for which it maintains liability. For example, no liability may attach to student mail, but most certainly the institutions must consider e-discovery implications of sourcing faculty and student mail, as well as materials sourced in course management systems or data centers. Entities such as Google offer services, such Postini, which the institution should consider as a part of its analysis in the context of its entire sourcing portfolio, together with whatever in-house technical, policy, and procedural approaches that the institution may already have in place and in which it may have made significant investments (for example, inventory materials, appropriate offices designated to engage with affected parties, technologies such as back up systems prepared to make non-deleting continuous back ups, and the necessary policy materials used to educate and inform affected parties).
Entity should be willing to warrant that they actually own the technologies and business processes foundational to their operations and indemnify the institution against any potential patent infringement action that should come about as a result of its technologies or business processes.
Entity should make explicit in the contract exactly what other terms of the agreement are included by incorporation via links, URLs, or any other documents associated with the contract. Moreover, the entity should promise not to alter any of its material terms in those incorporated documents and to service notice on the institution and/or its users in the event of any non-materials change.
The United States has specific export control laws which the institution and/or its users may be in violation of if the entity stores (and possibly even if it transmits) certain kinds of encryption software not allowed outside of the U.S. In the event that the vendor/entity has data and/or routing centers outside of the United States, the institution must either restrict such users from those services, or contract with the entity to promise that such data is neither stored not transmitted outside of the United States.
The institution should insist upon clear language from the entity about how much lead time each party requires before implementation of the agreement and what, if any, penalty exists for failure of a timely implementation.
The parties should make clear for what specific reasons either party can suspend or terminate the agreement (taking into account a reasonable time period for the institution to either rebuild its services or to shift to another vendor) as well as how, in what ways, and in what time frames the institution will have access to its information, stored or continuing to be transmitted, before, during, and after suspension or termination period. In the case of institutional information, the contract should be crystal clear about what happens to the information after termination of the contract; one could hardly imagine a case where the rule would not require the entity to instantiate that information for the institution and to destroy its copies.
The institution should outline the specific circumstances whereby it demands and expects information from the entity or vendor, for example, in instances of a concern for the health or safety of a student, to check on that student’s use of e-mail services and possibly even the content of his or her e-mail messages. The institution should review its existing or desired practices in this area (death of student, health or safety emergency of the individual, health or safety emergency of the institution or other people) and establish a process by which affirmations may be offered as to the circumstances and promises for prompt response, especially in urgent emergency circumstances per an agreed upon procedure. In the case of faculty and staff mail, again the institution should first review its own policies and procedures for access or disclosure of such information (content as well as system and network logs) and attempt to incorporate such access rules and procedures in the context of the relationship between the vendor and the institution. Additionally, the contract should incorporate the ability to review the procedures for effectiveness and efficiencies according to technological, social, or other changed practices.
Most likely, vendors or entities do not provide a warranty of anything! This area of the contract can be a "throw away"—that is, a meaningless term stating that the entity makes no warranty (which, in the case of negligence, will not absolve its liability). Indemnification is the other side of the coin. It is not reasonable to list out every possibility of what a vendor might attempt to indemnify itself against in a contract. The institution should nonetheless scrutinize this section carefully to see whether the entity is using the section as a "get-out-of-court-free card" or similar kind of provision or if the entity has narrowly tailored the section to indemnify it against actions that are in fact not its responsibility.
By contract, vendors commonly choose their own jurisdiction. The preferred position is to eliminate this provision from the contract altogether and rely on existing jurisdiction law in the event of a suit. In most cases that means that if the vendor brings a suit against the institution, default rules of civil procedure require the vendor to bring it in the institution’s location, which usually, although not always, is the preferred posture.
For more examples of specific contract language, please see Appendix B: Sample Language for a Google Mail Contract.
After all of the cost/benefit and fit analysis (impact on users, personnel, and IT provisioning, to name just three factors) has been done on a question of outsourcing a particular information technology to a cloud service provider, the larger question remains: will the outsourcing of this service, combined with any other already outsourced services or as a package of services to be outsourced as a part of a strategic plan, render the institution unable to control the services that support its missions?
The process by which the institution attempts to answer this question is as important as any one particular answer because it necessarily requires coordinated thinking among the senior management of the institution. Therefore, it is critical that a process be established, perhaps reinforced by policy, to assess not only particulars of one contract but the overall impact that outsourcing in general has on the institution. In short, the whole may be greater than the sum of its parts. Without coordination at the highest levels, the institution may not be aware of the total impact of campus-wide outsourcing until it is already in a vulnerable state or in a reaction mode following an immediate crisis. Outlining contingency plans in the event that a provider’s services fail or that the provider goes out of business or is in breach of contract addresses only a sliver of the risks at stake. Indeed, the institution should have a full-scale instantiation plan for recovery of services across the board of its outsourced portfolio, as well as a detailed understanding of the intricate interdependencies that exist among and between services and the full and unhindered exercise of its missions.
A comprehensive, high-level view of this matter also generates another series of important questions that higher education is behooved to ask in this information economy global environment. First, rather than contracting with commercial vendors, what about taking advantage of collaborative possibilities or potentialities arising from, for, and by higher education? To that end, a number of options have begun to emerge from the academy; the most thoughtful one is included as Appendix C to this document. Second, could individual institutions identify and contract with other higher education partners for services and/or research? Cornell University Library, for example, is working with Columbia University on consolidating some services related to their collections. Might staff and faculty find collaborators in other administrative units and/or academic departments around the world, working on any variety of service support or substantive academic research? Finally, if working with commercial vendors is, all things considered, the appropriate option, then how can institutions work together to create a baseline of contractual agreements that meet the particular regulatory and service needs of colleges and universities? How can they place commercial vendors in the position of competing with each other instead of making colleges and universities compete between and among their own kind? At the very least, the non-disclosure provisions in many of the already existing contracts with vendors need to be revisited if they are the first barriers to collective efforts on the part of higher education to advocate for its enterprise effectively
Prognostications about the future of higher education fill an entire range of possibilities, from its complete disintegration as a result of the combined effects of commercialism and disintermediation of instruction via information technologies, to a complacent notion that, having survived and in some cases thrived in the last millennium, it will continue to do so in the next. As is usually the case with prognostications in general and given what we know about this spectrum of opinions in particular, the future landscape will probably fall somewhere in the middle. A growing consensus tends to hold that a top tier of colleges and universities, so long as they maintain smart strategic directions in the scope of their services and exercise of their missions, will remain largely intact although certainly altered, for example, as a result of multi-purpose collaborations internationally and by incorporating distributed information technology teaching and learning tools and techniques to enhance, but not supplant, traditional means and methods of research and instruction. Institutions that are neither as well endowed nor established, and those that are mismanaged, may face significant if not lethal challenges from competition with savvy and nimble for-profit educational companies due to their inability to swiftly and wisely redirect or contain internal costs. Furthermore an emerging divide between education in the liberal arts model of critical thinking and education as training for specific tasks alarms a number of observers, even as they support, for example, the Obama Administration and the emphasis that it is placing on community colleges as a means to assist less advantaged economic classes and to compensate for the entrenched inadequacies of public K-12 education in many communities that have been going on for a generation or even more, as we advance into the twenty-first century.
The potential of a short term economic fix through outsourcing evolving into a major vulnerability for higher education at some future point through the failure to control the services that support our missions has not, however, been an issue fully explored in this larger debate. It should be. The risk is not too readily apparent and the benefits, especially if one looks only to finances, appear propitious, which ultimately has rendered the issue one that runs below the proverbial radar of American higher education’s leaders. That higher education will continue to deploy information technology is a given. Most observers recognize that information technology will continue to develop along the lines of cloud computing. What remains unclear is how and in what ways higher education will either take an advantageous position in the course of these transitions or suffer in the loss of revenue and morale. Prudent, open, and self-conscious consideration of the serious issues that lie between “the cloud” and outsourcing within and among our institutions is not merely a defensive measure to protect against particular risks of legal liability or system failures but the smart, innovative direction that makes the efforts of its leaders to address these sometimes elusive issues worthy of the enterprises’ fundamental ambitions and missions.
In its broadest usage, the term cloud computing refers to the delivery of scalable IT resources over the Internet, as opposed to hosting and operating those resources locally, such as on a college or university network. Those resources can include applications and services, as well as the infrastructure on which they operate. By deploying IT infrastructure and services over the network, an organization can purchase these resources on an as-needed basis and avoid the capital costs of software and hardware. With cloud computing, IT capacity can be adjusted quickly and eas- ily to accommodate changes in demand. While remotely hosted, managed services have long been a part of the IT landscape, a heightened interest in cloud computing is being fueled by ubiquitous networks, maturing standards, the rise of hardware and software virtualization, and the push to make IT costs variable and transparent.
Cloud and cloud-like solutions appear to be widespread and growing in higher education, though in relatively focused areas, such as student e-mail. E-mail notwithstanding, higher education institutions are more likely to obtain new services from the cloud than to transition established services that have long been operated by the campus. Many colleges and universities see pockets of cloud service usage in other areas, often led by individual faculty or students looking for the added flexibility and convenience that the cloud can provide. Among the drivers that are encouraging more institutions to contemplate cloud services are budget pressures, calls for increased reliability of and access to IT systems, and the need for institutions to provide timely access to the latest IT functionality.
In traditional enterprise computing, IT departments forecast demand for applications and capacity and invest time and money to develop those resources in-house or purchase them from others and operate them in-house. With cloud computing, institutions procure IT services from remote providers, and campus constituents access these resources over the Internet. E-mail, for example, long considered a staple of an institution's IT operations, can be obtained from a range of sources, and a growing number of campuses contract with outside suppliers for this function. Software is hosted by the provider and does not need to be installed—or maintained—on individual computers around campus. In some cases, a large university or a consortium might become a provider of cloud services. Storage and processing needs can also be met by the cloud. Institutions pay only for the resources used, and users can access the applications and files they need from virtually any Internet-connected computer. In a mature cloud computing environment, institutions would be able to add new IT services or respond to changes in capacity on the fly, saving capital costs that can be redirected to programs of strategic value to the institution.
Cloud computing presents IT organizations with a fundamentally different model of operation, one that takes advantage of the maturity of web applications and networks and the rising interoperability of computing systems to provide IT services. Cloud providers specialize in particular applications and services, and this expertise allows them to efficiently manage upgrades and maintenance, backups, disaster recovery, and failover functions. As a result, consumers of cloud services may see increased reliability, even as costs decline due to economies of scale and other production factors. With cloud computing, organizations can monitor current needs and make on-the-fly adjustments to increase or decrease capacity, accommodating spikes in demand without paying for unused capacity during slower times. Aside from the potential to lower costs, colleges and universities gain the flexibility of being able to respond quickly to requests for new services by purchasing them from the cloud. Cloud computing encourages IT organizations and providers to increase standardization of protocols and processes so that the many pieces of the cloud computing model can interoperate properly and efficiently. Cloud computing’s scalability is another key benefit to higher education, particularly for research projects that require vast amounts of storage or processing capacity for a limited time. Some companies have built data centers near sources of renewable energy, such as wind farms and hydroelectric facilities, and cloud computing affords access to these providers of "green IT." Finally, cloud computing allows college and university IT providers to make IT costs transparent and thus match consumption of IT services to those who pay for such services.
Cloud computing introduces significant concerns about privacy, security, data integrity, intellectual property management, audit trails, and other issues. Because higher education is subject not only to institutional policies but also to a broad range of state and federal regulations, these issues are complex and become even more difficult in the context of inter-institutional cloud initiatives. Because of the control that consumers of cloud services cede to providers, successful initiatives rely on a high degree of trust between a college or university and a supplier, including confidence in the provider’s long-term viability.
The emergence of cloud computing as a viable option for a growing number of IT services speaks to a level of Internet penetration and infrastructure maturity that did not exist just a few years ago. Analysts expect cloud computing to see mainstream adoption in 2–5 years, and some higher education IT leaders believe that cloud computing programs on campus will increase considerably in the coming years. To the extent that these efforts are successful, confidence in the model and trust in providers will grow, and institutions will be more amenable to transferring a larger number of services to the cloud. Conversely, a breach of trust by a cloud provider would likely leave institutions uneasy about cloud services. Although the benefits of cloud computing are becoming more tan- gible, significant policy and technology issues must still be sorted out for it to reach its potential. Even as "public" clouds are being developed, a new class of "private" clouds is taking shape. Whereas public cloud providers offer relatively undifferentiated services, private clouds pursue similar economies of scale but do so while preserving the ability to customize applications and services for consumers. Large organizations, such as statewide offices for higher education, for instance, might invest in cloud services for all the institutions in the system. As greater numbers of campuses consider cloud computing, services that have institutional identification or integration needs are less likely to be sourced from the cloud, and a heterogeneous mix of services—some from the public cloud, others from private clouds, still others developed in-house or purchased and customized—is likely to characterize most institutional IT portfolios.
Colleges and universities are expected to provide a wide and growing array of technology services, some of which are highly specialized or idiosyncratic to individual campuses, whereas oth- ers simply need to be available. By offering commodity services over the Internet, cloud computing offers one way for institutions to increase operational efficiency and focus scarce resources on services that are institutional differentiators. Operating in a cloud environment requires IT leaders and staff to develop different skills, such as managing contracts, overseeing integration between in-house and outsourced services, and mastering a different model of IT budgets. Cloud services might facilitate inter-institutional collaboration because they are more easily accessed by students and faculty at disparate institutions. In addition, despite the potential security risks posed by cloud services, some would argue that cloud services offer more security than on-campus solutions, given the complexity of mounting an effective IT security effort at the institutional level.
www.educause.edu
August 2009
V. Sample Language
Below is a grid of sample language addressing some of the issues noted above. Section numbers correspond to provisions as outlined in one institution's contract with Google regarding mail, although the language is generalized and can be used in any other kind of contracts and with other vendors.
|
Section |
Issue |
Comments |
|
1.2 |
Security |
Google promises to “adhere to reasonable security standards no less protective than the security standards at facilities where Google stores and processes its own information of a similar type” and states that it “has implemented at least industry standard systems and procedures to ensure the security and confidentiality of Customer Data, protect against anticipated threats or hazards to the security of integrity of Customer Data, and protect against unauthorized access to or use of Customer Data.” While this sounds good in the abstract, it is open to considerable interpretation and argument. It would be preferable to specify an actual, specific, independent security standard. In addition, previous iterations of the contract acknowledged that customer data “may be stored and processed in the United States or any other country in which Google or its agents maintain facilities” and required us to “consent[] to any such transfer, processing and storage of information.” The deletion of this provision presumably does not mean that Google has changed its practices, but, rather, simply that Google doesn’t want to discuss the issue. Given the lack of legal protections in some countries in which Google operates (consider its experience in China), it would be preferable to limit customer data to the United States to the extent possible. There may also be EAR/ITAR implications to this. |
|
1.3(a) |
Modifications |
Google reserves the right to make “commercially reasonable modifications” to the service unilaterally. While some form of right to make changes probably is necessary and appropriate – and we certainly have no objection to improvements – what is “commercially reasonable” in the context of a “free” service could be expansive. It would be preferable to add a qualification prohibiting “materially detrimental” modifications. |
|
1.3(b) and various others |
Incorporation of URL terms |
The contract incorporates a number of additional terms and policies posted on various Google web pages, which Google reserves the right to amend unilaterally – which means that the contract is incomplete and potentially meaningless, because Google could change it significantly at any time. However, if any such amendment is “material,” Google will “alert” the institution via e-mail or the administrative console, and the institution may object within 30 days; if it does so, the amendment will not apply to the institution. If Google is willing to waive such changes, it should be willing simply to agree not to make them for the term of the agreement. (That would also relieve Google of having to keep track of numerous variations among its customers.) At the very least, there should be a prohibition against “materially adverse” changes. Moreover, the incorporated terms are not always consistent with what is in the contract or with other sets of incorporated terms – which means that the contract is in some cases unintelligible. It would be preferable if all contractual terms were in the contract itself, with only technical guidelines and similar “non-legal” matters dealt with elsewhere. We need to address the issue of ownership of derivative works creating using Google’s APIs. |
|
1.5 |
Privacy (and FERPA) |
Google promises to comply with its “Privacy Policy and . . . Privacy Notice,” but both are URL terms that may also be amended unilaterally. Moreover, there are actually some 30 separate privacy policies, none of which really explain what Google really does in terms of data mining. Under FERPA, much faculty and staff e-mail will constitute “education records,” which means that we cannot provide it to Google unless we designate Google as a “school official” to which we have outsourced the operation of our e-mail function, which means in turn that Google may use that e-mail “only for the purposes for which the disclosure was made” – that is, for the purposes of operating our e-mail function, not for data mining. Moreover, under the proposed new FERPA regulations, outsourcing contracts “must ensure that the outside party does not use or allow anyone to obtain access to personally identifiable information from education records except in strict accordance with the requirements established by the educational agency or institution that discloses the information.” There may be similar requirements under other statutes governing the privacy of specific types of information. It is possible that the Postini service could resolve this issue, if it provides encryption in both transmission and storage. |
|
1.6 |
Ads |
While Google generally won’t serve ads (except, under certain circumstances, to alumni and volunteers) to users of Apps, note that it presumably will use the information that it gathers from their use of Apps to serve ads when they are using other Google services. |
|
2.1 |
AUP compliance |
We are required to use “best efforts to ensure” that our end users comply both with Google’s AUP (another URL terms incorporated by reference) and the contract. That is appropriate with respect to faculty and staff, for whom we are vicariously liable, but it would be preferable to provide simply that we will “inform” our students, for whom we are not vicariously liable and over whom we have little control, of their obligation to do so. Moreover, if Google continues to include the contract within the definition of “Confidential Information,” it is unclear how we can even “inform” our students of their obligation to comply with it (let alone how it applies to them in the first place). |
|
2.4 |
Privacy |
Note that we must “protect the privacy rights of [our] End Users under all applicable laws and regulations” and “obtain and maintain [their] consent” to whatever “access, monitoring, use or disclosure” of their data in which we engage and to Google’s provision of the tools by which we do so. This should be covered generally in our existing AUPs and privacy policies, but we may need to conform them. It’s not entirely clear why Google considers this a necessary contractual issue, but it may be in part an effort to disclaim FERPA responsibilities. |
|
2.5 |
Unauthorized use |
We are required to use “all commercially reasonable efforts to prevent unauthorized use” and to “notify Google of any unauthorized use of, or access to” the service of which we become aware, which seems burdensome and unnecessary. It would be preferable to state simply that we will not “authorize” such use, or, at least, to strike “all” and qualify the notification threshold with “material” or something similar. |
|
3.1 |
Requesting end user accounts |
This seems to provide that, once the service has started, we must set up new accounts by contacting Google, rather than online through the administrative console. It’s probably just bad drafting, but we should confirm. |
|
3.3 |
Automatic renewal |
The agreement renews automatically for additional one-year terms unless we give 60 days’ prior notice. This is probably not a major concern, as there is nothing in the agreement that actually requires us to use it (exclusively) for our e-mail, and there (currently) is no out-of-pocket cost. However, if we use any of the add-on services for which there is a charge, it will be important to use a “tickler” system. Ideally, the contract would renew automatically (so we don’t have to renegotiate every time), but also allow termination for convenience on 30 or 60 days’ notice. |
|
5.2 |
Suspension of end user accounts |
Google may suspend an end user for any violation of “the Agreement,” a standard which is unclear and open-ended. It would be preferable to provide a clearer and more restrictive standard. |
|
5.3 |
Suspension and termination of the service |
Google has the right to suspend administrative access upon certain events and “commercially reasonable notice,” and to terminate the service on 30 days’ notice. In order to make adequate alternative arrangements, we would need a minimum of 6 months’ notice. If necessary, we could agree to some form of escalation before termination and/or some alternative penalty. |
|
5.4 |
Emergency security issues |
Google has the right to “automatically” suspend an “offending use” in the event of an “Emergency Security Issue,” but the standard for what constitutes such an issue is unclear and relatively open-ended. It would be preferable to incorporate a materiality or similar threshold. |
|
6.1 |
Confidential information |
The parties may disclose “confidential information” only to those “who have agreed in writing to keep it confidential,” which seems an unnecessary burden. It would be preferable to provide simply that we are responsible for maintaining the confidentiality of such information or, at most, that we will “inform” recipients of their confidentiality obligations. In addition, the parties “may use Confidential Information only to exercise rights and fulfill obligations under this Agreement.” Given that “Confidential Information” includes “Customer Data,” which in turn includes e-mail, is Google giving up the right to engage in data mining? Also, it needs to be made clear that we (and/or our users) own our Confidential Information and Customer Data. (Section 7.1 acknowledges that we own the IP rights to our Customer Data, but does not clearly address other rights.) |
|
6.4(b) |
Third-party requests for information |
We are responsible for responding to subpoenas and similar third-party requests for information relating to an end user’s use of the service, but it is unclear whether the service gives us the tools necessary to do so (unless we purchase the Postini add-on, which raises its own set of issues, including whether it is possible to delete archived information). We need to clarify what tools are available, both in the basic service and in Postini, and how they work. |
|
8 |
Restrictions on use |
We must use “commercially reasonably efforts to make sure a third party does not” alter the pages through which the service is provided, modify information transmitted through the service, share service-related content or documentation provided by Google, re-sell the service, “attempt” to reverse engineer the service, and various other things. It would be preferable to provide simply that we will not “authorize” third parties to do these things. |
|
9 |
Publicity |
Google may include our names on customer lists. It would be preferable to further limit the use of our names to those which do not state or imply an endorsement. We may not make “any public statement” regarding our relationship with Google without Google’s consent, which seems overbroad and unnecessary. For example, this would appear to prohibit us, without Google’s permission, from making even a simple announcement to our faculty, staff, students, alumni, and volunteers that the service is available to them. It would be preferable to carve out factual statements about the existence and nature of the service to our community. Moreover, all provisions should be mutual. |
|
10.1 |
Representations |
Google warrants that it will provide the service “in accordance with the applicable SLA,” but the SLA is a URL term that can be changed unilaterally and doesn’t provide a great deal of assurance – the penalty for violating it is simply more free days of service. What are the minimum standards we need – 99% uptime? We are responsible for complying with COPPA, but (with the possible exception of Doogie Howser) it presumably is not applicable to us. |
|
10.2 |
Disclaimer of warranty |
Google disclaims essentially all warranties, including a warranty that the service does not infringe third party’s intellectual property rights, although it later provides a limited indemnification in that regard. |
|
11.1 |
Termination |
Google may suspend performance or terminate the agreement upon 30 days’ notice if we fail to cure a material breach or immediately if we materially breach more than two times. We need a minimum of 6-9 months to make adequate alternative arrangements. |
|
11.2 |
Effect of termination |
Upon termination, Google will give us access to, and the ability to export, customer data “for a commercially reasonable period of time at Google’s then-current rates for the applicable Service.” We need a minimum of 6 months to 1 year, and we need to know what tools and formats are available. Google will also delete our data “pursuant to the Google Apps Privacy Notice” and “after a commercially reasonable period of time.” The notice is a URL term that can be changed unilaterally, and the time period is unclear. It would be preferable to provide that the data will be deleted as and when we specify, subject perhaps to some set deadline. |
|
12.1 |
Indemnification by customer |
We are required to indemnify Google not only for our own actions, but also those of our end users, including students for whom we are not otherwise vicariously liable. This is largely an issue of who will pay Google’s attorney fees, as Google has good legal defenses against claims based on end user content or actions. Moreover, this is not really taking on a new liability, as we currently can be sued for such content or actions (and have the same legal defenses) as ISPs ourselves. Nevertheless, it would be preferable not to voluntarily accept that liability, which is also no different that Google’s liability for its other, non-institutional end users. Public institutions may also have significant state-law restrictions on their ability to indemnify. |
|
12.2 |
Indemnification by Google |
Google will provide a reasonably good indemnification for infringement of third-party intellectual property, but not for anything else, including inappropriate disclosure or data breach. It would be preferable to have an indemnification for all of Google’s acts and omissions, but at the very least it should cover these two. We also need to reconsider this if/as new Apps are implemented. (Must new Apps be adopted, or do we have the ability to pick and choose?) Also, we need to have notice of any security/data breaches, at least to the extent that user notification is legally required, and preferably in advance of user notification. |
|
14.1 |
Notices |
Notices must be addressed to the other party’s legal department and “primary point of contact,” but no such point of contact is specified for Google. |
|
14.10 |
Governing law and jurisdiction |
The contract is governed by California law, and exclusive jurisdiction over disputes is in Santa Clara County, California. Public institutions may have significant state-law restrictions on their ability to consent to such provisions, and they are inadvisable for others. It would be preferable to either (a) specify the law and jurisdiction of the customer (as Google operates in and is subject to all such jurisdictions), (b) provide that disputes must be brought in the defendant’s jurisdiction (which is even-handed and tends to encourage informal resolution), or (c) simply delete the provision and leave the question open. |
The following essay offers some unrefined thoughts regarding how models for aggregating scale in IT services – clouds, software as a service (SaaS), infrastructure as a service (IaaS) in today’s lingo – may evolve for universities. Its purpose is to encourage thought, surface assumptions, and spur dialogue to help reach a point of timely action by interested institutions. The focus is on the needs and abilities of R1 institutions, though the ideas may have merit for others as well. I hold as an assumption that the aggregated services of greatest interest to institutions must have some sustainable economic model, so in some respects, they are not hugely different from the Service Bureaus that preceded them decades ago – though the connection speed has vastly improved.
The central question is to what extent should IT services be aggregated and why? If there is an affirmative answer to aggregation, then the second question is through what models should IT services be aggregated, provisioned, and governed?
The aggregation question is familiar territory for campus IT leaders, and it is often part of an ongoing balancing of service provision among edge and leverage. For simplification, edge means a service is provisioned by an academic/administrative department as desired and leverage means it is provisioned through some aggregation. For many of us, we long ago aggregated campus email services into a common, leveraged service. Likewise, we did this with Course Management Systems and administrative systems. We did so to seek efficiencies in the total cost of operations and in providing a common platform for users who move among schools and departments. We have also chosen to rely on edge provision for some services where specialized domain knowledge, proximity of staff (i.e., boots on the ground), lack of net efficiency gain via aggregation, agility, or frankly politics made this the better choice. In some cases, service provision can be productively split between some leveraged back office component and some edge, local services component. It is useful to note that, though similar, Edge/Leverage is not the same as Centralized/Decentralized, but that is another paper.
Thus far, most of our aggregation questions have been in the realm of aggregation in a school, on a campus, multi-campus institution, or possibly some in state consortium. Growing network capacities, perceived commoditization of some services, and service offerings from Amazon, Google, IBM, and others proffer a level of aggregation for service provision that is ‘Above Campus.’ They also offer services directly to campus units, enabling horizontal aggregation across campuses rather than vertical aggregation on a single campus.
For example, the College of Engineering at a dozen institutions could choose to aggregate email or another service and individually or collectively contract it to a commercial firm independent of campus aggregation. In essence, the commercial firm becomes the coordinating mechanism for aggregation rather than the CIO. Is that a problem? I don’t think so if it is done in a policy-compliant way that does not impose unacceptable risks on the institution. Is it the best path? I remain skeptical in the sustaining value of these arrangements over time, but some services can evolve on short-term bases due to low switching costs.
It may be helpful to further define the terms IT service and provision. A service could be something like an email account, remote PC backup/archive/retrieval, data set storage, support desk, HPC MPI code optimization consultation, licensed software distribution, etc. A service also has elements of contracting, legal/policy compliance, evolution and improvement, measurement regarding cost/effectiveness, and user support, etc. as essential parts of an overall service. Provisioning defines the means through which these components of a service are made available, e.g., in an academic department, via a shared service unit of a campus, through a consortium like HathiTrust, or as a free or for-fee service on the Internet. At present, I would not include Sakai, Kuali, or Fedora as provisioning IT services, but the CIC’s OmniPoP for networking, HathiTrust for scanned books, and of course, Google or Microsoft Live mail are examples.
The two questions posed above proffer a matrix for considering types of IT services and means of provisioning (Models). The models seek primarily a means to achieve economies of scale in efficiency and innovation that would not otherwise be accessible within an institution. Scale, however, requires some commonality and standardization. It seems unlikely in the near term that institutions could operate their financial systems in an above campus model for scale (other than simple hosting) as the disparity and specialization to each institution remains large (the merits of that disparity regarding the core missions of research and education could be another essay).
One option, of course, is that institutions could entirely drop providing a service through any means. They could direct individuals to make use of the public services of their choice through their own means (e.g., personal email, S3, Flickr). For services that are to continue, I’ll propose four provisioning models though the fourth one has two variants.
An illustrative and incomplete matrix might look something like this for a particular institution (Summer 2009):
|
Model: IT Service: |
Baseline |
Commercial Sourcing |
Institutional Sourcing |
Consortium Sourcing |
|
DNS Backup |
Current |
|
Planned |
|
|
|
|
Current |
|
|
|
Clinical Data |
Current |
|
|
In Development |
|
Classroom Videos |
Pilot |
|
|
Desired |
|
…etc. |
|
|
|
|
The Commercial, Institutional, and Consortium sourcing models essentially differentiate on the basis of the coordinating mechanism used to achieve economies of scale in operations and innovation. Each involves a money flow from institutions to an aggregation point for service provision. I believe there are many subtle and important differences in these three models that merit extended scrutiny. History instructs us that each model has a potential risk and reward profile, and no model is a silver bullet over the full lifecycle of an IT service.
I suspect that answers for each institution will vary, and answers for an institution will shift over the years as the risk and reality of the services and the models mature. For a specific IT service, some institutions may already have sufficient size and scale to hit favorable economics, and some institutions can aggregate across multiple campuses to achieve favorable economics. For other institutions, simple two- or three-way partnerships may produce scale at low coordinating cost.
The COMSo model is generally well understood in the realm of standardized uses. For example, few institutions print W-2 tax forms in-house or provide online access to them over the years. Most of us use a COMSo model for this as it is economically efficient and addresses a highly standardized service requirement even if there are variations in our payroll systems and data. Contracting with one provider or another, switching providers should there be issues, and dealing with service level agreements is not onerous for an institution. It is doubtful that aggregating demand from multiple institutions to contract with a single commercial firm would yield cost reductions over the increased coordination costs. Few of us care how to become experts in W-2 services. Thus, for this commodity service that is similar across many industries, it is economically efficient for 1:1 contracts and loss of any organizational learning from this activity.
Without any surprise to my colleagues, you will rightly anticipate that I find the Consortium Sourcing model the most promising for IT services that are core to our primary missions of research and education over the next 5-10 year horizon. I will use the remainder of this essay to focus on opportunities and challenges for CONSo, and I am hopeful that others will expound upon the CONSo and INSo models.
For IT services that are critical to research and education – research data sets, the scholarly record, course materials (particularly in evolving fields), etc. – we seek efficiency, but we must also nurture innovation and skills in these areas. The domain for consuming these IT services, or more properly IT-enabled services, spans beyond a single institution. For example, physicist and geneticists around the world compete and collaborate on data, models, and publications that advance collective knowledge. Instructional materials are shared via for-fee and open models. In short, I believe that attributes of the CONSo model may provide the best long-term fit for core IT services.
Three attributes of CONSo are particularly appealing. First, I believe that aggregating demand and turning it into an IT service with a price point and governance mechanism is the bulk of the work. HathiTrust essentially did this when it aggregated demand across the CIC institutions and the California Digital Library for the Google book scanning project. Each institution needed a means for ingesting book page images and metadata back from Google, curating it for the long term, and provisioning services within the allowances of copyright. At its launch, the service is provisioned by the University of Michigan and Indiana University as the repository operators with full redundancy. In time, it could be provisioned by Amazon or the California Digital Library without having to renegotiate all the upfront work that aggregates the demand, defines the service, and governs its evolution.
Second, there will be inevitable governance decisions that are steered by values. I believe that we have a better chance of steering service evolution to reflect the deep values of higher education when we have a means and sufficient influence to do so. Aggregating demand via a consortium provides a means to ensure that our values can carry the day over the business choices that do not serve our mission. Importantly, the CONSo model still enables market efficiencies by provisioning the service via economically-efficient providers over time.
Finally, higher education is developing the skills and know how to manage the digital book content at scale. I believe it is valuable for the academy to know how to do things that are core to our mission, and many of these skills are pioneering. Advocacy for the CONSo model for core IT services still affirms that other models may be a better fit for some types of services or even for some research and education core services at some points in time. Likewise, there may be some IT services, even seemingly pedestrian ones, where COMSo will be efficient for higher education.
My colleagues know that I have no illusions regarding the substantial challenges of sustaining multi-institutional aggregations of effort. It is those very experiences, however, that give me confidence that CONSo is a viable mean of accessing economies of scale in efficiency and innovation beyond what any institution can do on by itself. How many consortiums? Fewer is likely far better than more, and in some cases, we may find that existing collaborations / organizations, e.g., Fedora Commons?, Kuali?, RONs?, Internet2?, EDUCAUSE?, CIC? could be CONSo providers as well. I also favor light-weight coordinating mechanisms and agreements that can operate in a philosophy of solving problems when they arise over detailed contracts that will likely prove ineffective anyway in the face of real challenges.
If there is merit in the CONSo model, how do we get started? I anticipate that CONSo provision of IT services will likely come from a 'coalitions of the committed' approach. Institutions that see similar opportunities at similar times can choose to pioneer CONSo arrangements and build them so they are expansible to others later. It is entirely fair to balance risk and reward in these arrangements so those who take greater risks in the beginning do have a greater role in shaping services and governance. Not every institution needs to – and couldn’t possibly – participate in each CONSo service as it develops. Our community as a whole, however, will benefit from parallel development of CONSo services that we can each join in when or if it is a service model that meets our institution’s needs.
