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.

I expect that companies will begin rejecting 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.

Related recommendations include:

• 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.

DOUG LANEY BIO

Doug Laney is the Data & Analytics Strategy Innovation Fellow at West Monroe where he consults to business, data, and analytics leaders on developing new value streams from their data assets. He originated the field of infonomics and authored the bestselling book, “Infonomics: How to Monetize, Manage, and Measure Information as an Asset for Competitive Advantage.” Laney is a three-time Gartner annual Thought Leadership Award recipient, co-chairs the annual MITCDOIQ Symposium, and is also a visiting professor at the University of Illinois Gies College of Business and the Carnegie Mellon University Heinz College. Follow and connect with Doug on Twitter and LinkedIn.