I have already discussed the challenges of retrieving your data at the end of a SaaS contact, but wanted to take a look at this from the perspective of how to build data governance into a contract when it is being negotiated.
A few key points to keep in mind:
- You have maximum leverage with the vendor before you agree and sign the contract. From that point forward your leverage diminishes significantly.
- Your data is yours, but the SaaS model greatly reduces your access to it. With on-premise you typically have full access to the database and can draw data in multiple ways, whereas with SaaS you only have what the vendor permits you to have.
- This may not be the mind-set of all vendors, but as a general business principle it is in the interest of the SaaS vendor to make it as hard as possible for you to access your data. The more dependent you are on their tools the harder it is for you to move away from them.
Good data governance begins with a data governance standard for your corporation. Almost certainly the typical offering from all vendors will fall short of the data governance standard, and therefore there will be a cost/benefit/compliance discussion to be had as part of vendor selection. This must include your Enterprise Architecture function who should be arbiter of whether any proposed implementation is acceptable or not.
Inevitably there will be times where key stakeholders, often from the business area, want to select a SaaS solution that does not meet your data governance standard. This goes to the heart of data governance – do you have the right level of sponsorship? If the data governance standard is the first thing to be compromised then your data governance initiative has failed.
Data Governance Questions to Include in Requests for Proposals
This is not intended to be a comprehensive list of RFP questions on data governance, but the following should be considered:
- Will you provide a comprehensive data architecture document for your application, detailing the data elements in the application and how they relate to each other? A sample of data architecture document will be provided with the RFP response.
- How will you present the data elements for consumption outside of the SaaS application?
- Are all data elements presented for consumption? If not what is excluded and why?
- Is the presentation of data elements real-time? If not what is the frequency of updates?
- Is the presented data accompanied by change logs to allow the extraction of incremental changes?
- What APIs for accessing the data are included in the proposal? Are there limitations on the scope of the data that these APIs can access?
- What other clients have comprehensively accessed data from your application and will they provide references?
- What is the standard method of returning data to a client at the conclusion of the contract?
Contractual Terms to Include
Most SaaS vendors will come to the table with their standard contract and push to use that as the framework for the final agreement. Typically this will make references to the right of the client to their data and that data will be purged once the client requests that. However, the devil is always in the detail so make sure that detail is spelled out!
Your needs will vary depending on your company and business function that the SaaS application will support, but some generic contractual terms to consider are:
- Upon the request of the client the vendor will provide the complete data set in the original database format. The client may request complete data sets up to twice per calendar year.
- If the vendor will not provide the complete data set in the original database format then:
- The vendor must define in the contract the format that will be provided
- The vendor is responsible for demonstrating the accuracy and completeness of this data set
- Upon termination of the contract a copy of the original database will be placed in escrow and retained for five years. If the client determines that the provided data set is inaccurate or incomplete then the original database will be released to the client.
- The vendor will provide comprehensive documentation to enable the interpretation of the extracted data set.
- The vendor will provide the SQL or equivalent query code for X critical reports against the extracted data set (determine how many queries you need).
- At the termination of the contract the vendor will provide access to knowledgeable resources meeting the following profiles:
- Report developer, 200 hours
- Database expert, 100 hours
- API expert, 100 hours
- The vendor will provide the production environment or equivalent for 30 days after the delivery of the data set to permit completeness and accuracy testing.
- If the provided data set is determined to be incomplete or inaccurate then the vendor will provide another data extract at no cost and will extend the availability of the production (or equivalent) environment for another 30 days at no cost.
Vendor Reaction
Almost certainly the vendor is going to throw up roadblocks and claim that none of their existing clients have every asked for any of these terms, and those clients are 100% satisfied with the service they are getting. Also what you are asking for will be prohibitively expensive.
Fair points, but just because their other clients haven’t protected their own interests doesn’t mean you have to walk into the same trap. And yes, good data governance costs money. However in the long run it typically costs less than bad data governance, and if you are serious about protecting your data (and if you’ve read this far I’m expecting you are) then you will eventually have to pay to get your data back and negotiate the terms at worst time for yourself.
Conclusion
The best opportunity to ensure that a SaaS application meets your data governance standards is by writing the correct terms explicitly into the contract at the beginning. Almost certainly there will be pressure to compromise – good data governance requires the investment of time and money at the outset of an implementation, as well as during the lifespan of the application. However retrofitting good data governance into existing applications is even more costly, if possible at all.
Stick to your guns, beef up your Enterprise Architecture team and good luck!
