SAP Licensing – The Lowdown on Static Read
Last May, when Bill McDermott announced SAP’s empathy toward its customers and provided standardised scenarios relating to Indirect Access at Sapphire Now, even a cynic would have been forgiven for anticipating some substance around the new rules.
The optimists among us might have expected even more. Perhaps SAP was going to be the first of the software giants to radically simplify its licensing and provide solid, predictable rules that allowed customers and prospects alike to create business cases with clearly defined costs of investment?
This wasn’t the case. Two months on and not much has changed. There’s an underwhelming murmur of disappointment amongst the customer base.
In this blog, we look at one of the three defined scenarios announced at Sapphire Now – “Static Read”. There are clear defined rules about what “reading data” means which makes it impossible to misinterpret. Coming from a Computer Science background I find logic compelling for the very reason that it cannot be misinterpreted. It’s yes or no. But what if it’s “SAP logic”? Things get difficult.
Consider a standard right of organizations. Their data is their own.
So, if an SAP customer pulls data from their SAP system and moves it into a static table (one that remains the same after any queries have been performed against it) then said customer, and owner of the data, would (should) be free to do whatever they want with it? So, how is Static Read even a point for discussion? Unfortunately, it is and it’s important to understand the nuances so as not to get caught out by hefty charges for existing configurations and when introducing new third-party solutions to the SAP environment.
Logically defining “Static Read”
Let’s start by determining when a process does not fall into the Static Read category. In simple terms, the act of reading data in isolation means that the data is unchanged. Therefore ANY function which causes a change in the underlying data, the opposite is true. If functions or processes performed by a third-party system change data in the SAP system, this is not a Static Read of the data.
So, by using a negative test, we should be able to come up with a firm answer. If data is NOT changed by a third-party system, then the process IS Static Read. Right?
Wrong.
Herein lies the problem. The word in front of read is “Static”. “Read”, in isolation, is a locked-down term. In the context of database terminology, it’s meant the same since the inception of the database as outlined above.
But what does Static Read mean? Well, adding this seemingly innocuous word essentially removes the clarity. It makes it an SAP definition, not an industry-approved definition.
And with this, there are caveats. The most crucial is that SAP has defined that: “data must NOT be exported in response to a query”. This means that the data must be pulled from SAP using some other method. The obvious one being a scheduled data dump. But then, what data can be dumped? What form must it take? In other words, how raw must the form of the data be to ensure that it hasn’t been processed too much so that it is considered a query?
And then, there’s the question about timing. Imagine, for example, that a company wants to run regular reports using an external reporting solution. Does SAP consider a data dump to be Static Read only when the extraction takes place in greater than X minute intervals? What about the frequency? Does the volume matter? Does the intended use of the data make a difference? Theoretically, none of this should matter. In practice, it almost certainly will.
So, unfortunately, any SAP customer looking for steadfast definitions must seek further clarification at the point of negotiation. If that negotiation arises from a new purchase, then you as the customer should expect to be in a strong position to further define the terms and conditions of Static Read for your organization. If the negotiation arises because of an audit, expect the situation to be more in SAP’s favour than yours.
What to do about it
As ever, preparation and improved visibility strengthens whatever position a company finds itself in. If you believe that there are third-party systems already in the SAP environment that can be configured to be read-only but currently are not, look to reconfigure them accordingly.
Often, in a complex environment no one person will be aware of all the systems which interact with SAP. In this case, you should use an aggregated solution such as Snow Optimizer for SAP® Software to ascertain where Indirect Access is taking place and work to build up an architectural diagram which includes details on data flow. Highlight where configuration changes may be possible.
When the time does arise for negotiation, be open and honest to SAP but also demanding. Make sure you get the clarity you require to deliver a level of certainty that enables concrete business cases when considering new solutions. In this way, you can be as close to logical and predictable decisions as it’s possible to be.
If your organization uses third-party applications, or employs Business Analytics platforms to access data held in the SAP environment, you have a major SAP indirect access risk that needs to be addressed today. Please download a complimentary copy of the Garner report: Customers Must Resolve SAP Indirect Access Risk When Investing in SAP Functionality by clicking on the image below.