I had the privilege of speaking with Michael Stephens for his upcoming Fall 2013 Hyperlinked Library MOOC at the San Jose State University, School of Library and Information Science. The topic of our conversation was participatory library service, community engagement, the use of teams, and a few other interesting issues.
Shortly after I got my first computer in 1982 — a Commodore VIC-20 — I started looking for information regarding games, programming, computer hardware, etc. One of my first dependable sources for information came in 1983 when I began watching a new PBS television show called Computer Chronicles, hosted by Stewart Cheifet.
This week, Cheifet is interviewed on Leo Laporte’s Triangulation. It’s a good interview, with lots of discussion about the early days of personal computer technology. And, if you’re interested in viewing any of the old episodes of Computer Chronicles, you can find them all at the Internet Archive.
Until only a few years ago, most of the software we purchased was installed on servers located in datacenters we owned. Sometimes we managed the software, sometimes an outside vendor managed it for us. But the software was almost always on a physical server housed under our control.
But this is 2013, and many government and private organizations have adopted some variation of a cloud-first strategy. A large number, if not a majority, of the services we purchase are delivered via software located on servers outside of our physical control. Our websites sit on Rackspace or Amazon or SquareSpace servers. Our HR/Payroll software may reside on a Sage or Kronos or SAP server cluster. Even our ILS software is now often based remotely in a Polaris or LYRASIS datacenter. Bibliocommons, probably the best discovery layer available, is offered only as a hosted solution.
The point is, many of our tools which we formerly put on local servers are now run from remote servers. Whether you call this “cloud” or “hosted” or “remote”, it all boils down to the same thing — someone else controls the hardware and runs or manages the software. You and your library are no longer in full control regarding access and management. (For this post, I will use the phrase cloud-based to refer to any software installed on a server or cluster of servers outside of your physical location.)
Don’t misunderstand. I am a huge proponent of cloud-based services. They are often easier to manage, better protected, more feature-rich, and cheaper to procure than the old solutions. But the steps we have to now go through to select and purchase cloud-based services has fundamentally altered the procurement process. We used to source software, perhaps purchase some professional services and maintenance, and sign a simple contract reflecting these points. With cloud-based services, the procurement process has been dramatically altered and it is still changing.
If you are about to purchase a cloud-based product, you have a few more things to investigate than you did in years past. I have placed links at the end of this post that direct you to several of the sources I use in reviewing cloud-based services and contracts. It’s easy to get lost in the large amount of information and recommendations in the documents, but it helps to see what’s discussed most frequently. You will want to follow your local organization’s purchasing policy with regard to contract formulation. But if your organization has not rewritten its cloud-computing contract and procurement requirements, you may want to start lobbying today. If you are responsible for your organization’s data and/or network, you may want to counsel change. I strongly suggest consulting your organization’s legal advisor for assistance in finalizing any contracts.
There are a myriad number of points you could insert into cloud-based contracts. If you research the documents linked below, and the many articles available on crafting cloud-services contracts, you will see just how many variables are involved. Here are a few things I now look for when buying a cloud-based product:
Things will break and there will be outages. You want to make certain that your contract clearly spells out response times for service interruptions, compensation for major outages, and what key performance metrics will be identified as measures.
Does the vendor notify you of outages? How quickly? Is there a Help Desk ticketing system in place for your use? How many services or people need to be impacted before the issue is automatically escalated? Before compensation kicks in?
If the outage or service interruption results in corrupt or lost data (not a data breach), what are your options for recovery and/or compensation?
If the vendor updates the service and specific functionality that you depended upon is lost, what happens? Can you cancel your contract without penalty? Does the vendor have to compensate you for the lost functionality?
Not every possible scenario can be defined in the SLA, but it is this part of the contract you will rely upon when things break and service is interrupted. Make certain the SLA is easy to understand and looks out for your needs.
2. Data — Who owns it and who can get access to it?
Most U.S. public libraries do not have legal requirements to store data in a particular nation, but some government and private organizations do have this requirement. Make sure you know if yours is one of them.
If the cloud-based service breaks, does the vendor’s promise to repair everything include the restoration of your data? What kind of backups does the vendor maintain, and what is the frequency of backup?
If you cancel your contract, how long do you have access to your data and in what format can it be returned to you? If the data is in a proprietary format structure then it will be useless to you.
Security breaches happen, but the disclosure of personally identifiable information — of staff or customers — can have significant financial and PR ramifications. The vendor should have clearly defined security measures in place to protect your data. Similarly, the vendor should have contractually defined notification procedures in place for contacting you in the event of any security breach.
Who is responsible for damages, fines, etc? Security breaches can often result in large financial penalties and settlements and the contract should clearly define liability and any limitations. It does you no good if the vendor denies responsibility for data breaches and leaves you to cover all of the costs.
If an ex-employee or anyone else takes legal action against you and issues a legal demand to the vendor for your data, what will the vendor do to notify you of this action? Will you have legal recourse before the vendor discloses the data? Will you or your legal representative be able to review the data and remove any personally identifiable information before the vendor hands it over? Remember, the data is no longer on a server in your datacenter, it is not under your direct physical control.
How long does the vendor retain backups and archives of your data? Does this comply with any legal requirements your organization may have regarding data retention? And if you cancel your contract with the vendor, how long will they retain the data and what recourse will you have should litigation or law enforcement ask the vendor to turn over your data once you no longer are their customer?
3. Get me out of here — Ending your contract
What recourse do you have regarding termination of contract? You should be able to terminate the contract at any time. If a penalty is to be applied then this should be in the contract.
Also, as mentioned above, it should be stated how long you will have access to recover your data and whether or not your data will be retained by the vendor following contract termination.
Your data should be returned to you in a usable format. You should not have to rebuild databases in order to transfer the service to a new vendor. The format in which your data is accessible to you should be defined.
This is a simplification of the many issues that now come up in cloud contract negotiation. Cloud-based services have fundamentally altered the way IT manages and implements solutions. Now that the data and servers are no longer under our direct control we need to adopt new procedures and requirements that protect the library and its many interests. Getting these formalized may be complicated and time-consuming, but it is of vital importance. Make sure the decision-makers in your organization understand these new complexities. The old way of crafting software and service contracts has changed.
Documents & Links
If It’s in the Cloud, Get It on Paper: Cloud Computing Contract Issues, by Thomas Trappler via Educause
Creating Effective Cloud. Computing Contracts for the Federal Government. Best Practices for Acquiring IT as a Service (PDF), via the Chief Information Officers Council
Legal and Quasi-Legal Issues in Cloud Computing Contracts (PDF), by Steve McDonald via Educause
Best Practices for Negotiating Cloud-Based Software Contracts (PDF), a DoD ESI Whitepaper [8/5/13 link appears down]
Cloud Legal Project (U.K.) via the Centre for Commercial Law Studies (CCLS) at Queen Mary, University of London
Negotiating Cloud Contracts: Looking at Clouds from Both Sides Now, via Stanford Technology Law Review
Change can make any work environment stressful, and with stress often comes distrust. This article from HBR is a good reminder about how transparency, relationships, and shared success can go a long way towards creating a better working environment, no matter where you work.
Leaders can shift people’s thoughts away from threats by fostering an open, transparent environment in which everyone shares and discusses as much as they can about what’s really going on. This sends a strong signal to everyone’s lower brain that “trust is in the air”. One conversational ritual you might try is hosting regular sessions with your team members to talk about pressing issues, challenges, concerns.