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
Follow me on Twitter @Doug_Laney #infonomics #GartnerDA
Category: cdo data-and-analytics-strategies infonomics
Tags: analytics api applications apps big-data business-applications cdo chief-data-officer contract data data-extract data-integration data-ownership data-rights data-science legal microsoft oracle packaged-applications salesforce sap
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.