Courts restricting you access to your own data?
In a recent UK case, the England and Wales High Court court ruled that the use of a vendor’s API to access and extract the customer’s own data constituted a use of, not just the API, but also the vendor’s underlying application. As a result, the customer is required to have a separate application license for each individual who is using the customer’s applications that access the customer’s own data via the vendor’s API.
London-based Diageo has been a SAP customer since 2004. Subsequently it built two Salesforce apps that pull data from it’s own mySAP Business Suite database, housed on premises. However, it’s not quite that simple. Diageo licensed and uses the SAP PI interface to generate simulated transactions for extracting their data. Diageo’s intention is clear: “We just want our own data,” but the method is convoluted–necessarily so, given SAP’s notoriously sophisticated underlying data structures.
Sure, Diageo could have used other non-SAP tools to extract the data. But SAP (and other app vendors) could also be more magnanimous in allowing its customers to use its API for doing so, without the need to license every third-party application user accessing their own data. A £54,503,578 (about US$61 million) bill to access one’s own data does seem a bit steep.
But I’m not here to judge, just to warn that the courts seem thoroughly confused on the issue of data ownership and rights. This isn’t the only case of this type. In Australia, for example, a Telstra customer has been prohibited from getting access to his own usage data.
My colleague Dolores Ianni and I have anticipated such issues. In Predicts 2017: Licensing, Legal and Language Lessons for Data and Analytics Leaders, we issued the the following strategic planning assumption:
By 2020, 50% of organizations will reject solutions from vendors that contractually inhibit their ability to extract their own data.
This has particular ramifications for custom analytics solutions and data science, where pulling data from within packaged applications is required. Should all analytic application users be required to have licenses to the business apps that generate and store the operational data? We don’t think so.
Among other recommendations, Dolores and I suggest:
- Organizations should ensure that questions pertaining to the movement and access of data, including indirect data access terms and conditions, are included in the RFI/RFP process and clearly articulated in writing.
- Information management leaders and CDOs need to influence the procurement process by refusing solutions that inhibit the ability to move and access their data without incurring additional licensing costs.
- Data architects need to document the data life cycle, flow and access points (that are known or anticipated). These include data extracts, movement or access by individuals, custom applications, other third-party applications, and even the larger ecosystem of customer, partner or supplier applications that touch their systems. Data architecture vetting with data and analytics leaders should include not only the efficacy and efficiency of data architecture, but also the licensing/cost implications of data movement and access.
In short, even though it may be your data, getting it out of megavendor applications or service providers may prove to be contractually and litigiously costly. So be sure to avoid the kind of technical debt that comes with failing to negotiate or understand contract terms related to accessing your own data.
For more on this topic, see the Gartner publication SAP Indirect Access License Fees Can Be Significant and Unexpected.
(About the author: Doug Laney is vice president and distinguished analyst, chief data officer research, at Gartner. This post originally appeared on his Gartner blog, which can be viewed here).