In the analysis that follows, I will avoid much of the technical detail, sticking to a relatively simple way to explain the problem and what the judge in this case determined.
How does indirect access arise?
The 'indirect access' issue has been a running sore among SAP customers for some years. Essentially it boils down to this: SAP wants paying additional license fees where a third party system accesses data generated by SAP systems. This normally happens through a machine-to-machine interface but will likely mean that users who are not licensed by SAP on the originating system get access to data generated by the SAP system, albeit inside the third party system. To that extent, those additional users are not necessarily aware that they are accessing SAP data.
Diageo represents a fairly typical case where SAP systems generate data that is subsequently fed into Salesforce systems for the purpose of self service by customers rather than routing via SAP systems to Diageo call center agents.
In order to win, SAP had to show that the terms and conditions of the contract with Diageo contained language which allows SAP to make an additional charge. The judge ruled that is the case. Diageo for its part argued that the manner in which the data was transferred to Salesforce meant that the SAP enabling technology was acting as a 'gatekeeper' for the data rather than providing a means to access the data by additional users.
The pertinent points in SAP UK v Diageo
The ruling goes through the pertinent contract terms and from my point of view and regardless of any other argument, it seemed clear to me that SAP is on good ground. In defining a named user, (the basis upon which SAP can levy fees), the appropriate clause says that a named user is:
"...an individual representative (e.g. employee, agent, consultant, contractor) of the Customer, a Group Company, an Outsource Provider or a Supply Chain Third Party who is authorised to access the Software directly or indirectly (e.g. via the Internet or by means of a hand-held or third party device or system). The extent to which a Named User is authorised to use the Software depends upon his user category as set out in the schedule."
In the ruling, the judge said:
“Only named users are authorised to use or access the mySAP ERP software directly or indirectly. Named user pricing is the only basis on which the mySAP ERP software was and is licensed to Diageo.”
So far so good. But the judge chose not to rule on the quantum of fees that apply in this case, saying that:
“In my judgment, there is no applicable named user category for the Connect customers… They do not have access to source or object code. They do not have access to the functionality provided by mySAP ERP in support of the wider operation of Diageo’s business. They access business process functions and information from the database for the purpose of ordering products and managing their own personal accounts only.”
You might be forgiven for asking that if the judge could not determine the user type from the list of types included in the contract than how could she rule in SAP's favor? That may well be a question for appeal although the judge was equally clear that SAP's original claim of some £54 million, based upon Diageo's 5,800 customers who access via Salesforce (and hence to SAP data) was not sustainable.
The more fundamental problem for customers is that while software license contracts are usually written in terms that favor the licensor, the Diageo contract originated at a time when few people anticipated connecting SaaS applications to traditional on-premise applications provided by third parties.
SaaS land v on-premise pricing
In SaaS land, there were early debates about who owned what and specifically the data generated by SaaS systems. Over time, contract terms were refined to the point where it is generally understood that customers are licensing access to software but that the data held by the SaaS provider is owned by the customer. That still leaves open the question of what happens when one system attaches to another.
In the case of Salesforce, it operates a fairly straightforward model that puts the cost onus upon the third party ISV. In other words, if you or I choose to develop a system that runs on the Force.com and so take advantage of access to Salesforce generated data, then you'll pay Salesforce an annual fee, usually based upon revenue. That eventually gets passed on to buyers but remains largely hidden to the buyer.
In the on-premise word, the situation is different and in SAP's case, it prices a mixture of components but which always come back to the concept of the 'named user.' Unfortunately, that may not be the best way to license in an internet enabled SaaS world and, will likely get even more complex in an Internet of Things world. Why?
In the on-premises world, the number of users who have access to back office systems is often a modest fraction of the whole workforce. SaaS that delivers newer capability can readily put functionality into the hands of an extended group of users. In Diageo's case, this included their customers. It is an example of what Phil Wainewright might term 'frictionless enterprise.'
While the on-premises ERP world envisaged a full, end to end business process environment contained within a single system, it never fully delivered on that concept. It couldn't and was never designed to achieve that goal anyway. All of which still leaves the problem of pricing for indirect access.
Buyer advocates speak up
Buyer advocates argue that companies like SAP are simply being greedy and that there needs to be an alternative regime in place that better reflects the realities of 21st century internet based operations. Constellation Research's Chris Kanaracus for example said this of the judgment:
Constellation sides with the generally accepted industry parameters of indirect access, which should include the ability to process batch data; aggregate information into a data warehouse or other data store; access data for use in another system via data integration; and to enter data from a third party system.
The difficulty with Constellation and other arguments is that they are emotionally led and not necessarily rational. However, there is little denying the angst customers feel and which Kanaracus describes in the following terms:
Constellation believes that overreaching pursuit of additional money for indirect access fees is anti-customer, and at odds with the friendlier, easier-to-work-with image SAP has sought to project under the leadership of CEO Bill McDermott.
It's also counterproductive in the long run, as more viable options to move off SAP ERP emerge from competitors. And needless to say, it's horrible for a vendor's public relations and at odds with today's forward-thinking enterprise IT shops, which are looking to generate innovation and efficiencies through the combination of systems from multiple vendors—as Diageo did.
Vinnie Mirchandani, a long term and vociferous SAP critic goes further, believing that the decision may have important consequences:
If this emboldens SAP to become more aggressive in going after more customers, I am fairly certain it is going to accelerate the “coping strategies” – diversification away from SAP and partners - I have described in SAP Nation. Except that this time, they will also extricate SAP from the core. The reality in many SAP customers is that for all the talk of “wall to wall” coverage, the functionality actually delivered by SAP is pretty small. Lots of surround systems deliver the industry specific and other impactful functionality. Customers have tolerated SAP at the core, but the financial and emotional pain from constant threats of audits is a bit too much to bear.
Yes, it will cost those customers to migrate away from that core so in that sense it is “mutually assured destruction” for both sides.
Over the weekend, I took to Facebook to see what others have to say. The consensus view was that it is likely too hard, risky and costly for customers to rip and replace their SAP systems. Customers and SAP therefore need to come to an accommodation on this problem.
While I understand that argument, I am not quite as convinced - at least not in some cases. I have already seen examples where what would normally be considered 'core' ERP is being moved away from the hegemony of SAP and Oracle. Some (and it is only a few right now) customers are finding coping strategies, but it is far from easy at the center of large, central deployments where many years of development have been put into honing efficient business processes.
SAP will want to tread carefully. They will have known that the initial claimed quantum was going to fail but if there is to be an agreed price for what amounts to data transfer, then it will need to be pennies on the pound/euro/dollar. It isn't reasonable, let alone sustainable to expect customers to pony up large amounts, however useful that data access might be.
I discovered this over 10 years ago when trying to price a particular system that had POC, small, medium and large per user pricing models. In our case, we simply couldn't price well on a named user basis for a system that was starting with 500 users but which expected to reach 135,000 users over time. We eventually found a compromise but it was far from ideal.
As far as I know, no-one has figured out a good way to price for this kind of scenario when taken in the context of a much broader reach of the data generated by back office systems for third party application usage or, in the future, IoT.
It is important to note that this case only affects Diageo in the UK. There may well be other cases lurking out there where CxO's will be nervously poring over their contracts to assess potential risk. My sense is that the SAPUK & Ireland User Group needs to get involved in order to both establish who is at risk and formulate plans to address a problem which, far from going away, has taken a fresh turn.
Examining contracts may, of itself, not be enough. I have long complained about the dearth of good lawyers who can provide solid advice on this topic. To that extent, the providers - in this case SAP - have a distinct advantage in creating contracts that are not always scrutinized as well as they might be for terms that give the vendor an unfair advantage. And like it or not, when you sign a contract, that cements a position that can come bite you later on.
Finally; this case is not over and while Diageo may appeal, I expect SAP to endeavor to reach a settlement that doesn't rancor.
UPDATE: I received the following statement from SAP UK & Ireland User Group in response to this story:
“This case highlights the growing concern around indirect access. It’s a topic we raised at our annual conference in November, calling on greater simplicity and clarity from SAP on what constitutes indirect usage and the implications for licensing. We have also warned all our members to be vigilant and consider their individual licensing positions.
We are actively engaging with SAP at a global level as part of the SUGEN license charter team, and locally we have been running a number of events and webinars to help our members better understand the challenge and share best practice. However, clearly there is a lot of work to do, customers don’t like surprises and without greater clarity from SAP that is exactly what we could get. This is why we have two members of our board participating in the SUGEN charter and why we continue to raise the issue both globally and locally with SAP.”
Philip Adams, chairman UK & Ireland User Group
Clarification: A number of commenters are getting hung up on the 'data' and 'ownership' issues. These are important misconceptions because:
- The judge did not consider this is an issue about data but about software usage by certain individuals. This is a critically important point. This view may change if Diageo chooses to appeal.
- When you acquire software you are (usually) acquiring a perpetual license for a specific number of named users. Once you go beyond that number then the vendor is usually entitled to be paid an additional sum based upon whatever user type is specified in the contract. This point was not the subject of the judgment.