The Suspicious Timing of SAP’s Flip Flop on Processing in the Database
Executive Summary
- The ERD diagram oversimplifies relational databases.
- Complexities in relational databases mean that they are often not fully leveraged by applications.
- SAP targets low information buyers and provides a steady stream of inaccurate information around databases.
The graphic above explains SAP’s internal process of how SAP determines what is true and what technical viewpoints they will hold.
Introduction: How Amazing Are Databases
This article began as a discussion with some colleagues around how much the application leverages the capabilities of a modern relational database. I observed that while developing a new application and going through the data modeling process required a discussion of how the database would process the data that we stored and how that would be represented. Some of the things that were explained to me regarding what the relational database could do and what we could take advantage of seemed like magic. This relates to some of SAP’s flip flops on databases.
Our References for This Article
If you want to see our references for this article and other related Brightwork articles, see this link.
Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.
Working in the SAP space is like being caught in a time capsule. And SAP does not leverage the capabilities of modern relational databases. All of their promotion about HANA does not change this.
Multi-Tenancy: The Foundational SaaS Functionality
For example, one of the fantastic features of modern relational databases is multi-tenancy. However, how many SAP applications that were not acquisitions are multitenant? How much experience does SAP have, in its homegrown products, in multitenancy? Not S/4HANA, while marketed to the hilt, it S/4HANA in the cloud not only has hugely few customers, it will just be multitenant for “baby customers,” (as is covered in the article is S/HANA Designed for the Cloud).
A segment of people understand databases at the right level and can leverage their capabilities for new application development. That is, I am not talking about turning an existing database or creating structures to support reporting; I am talking about building entirely new applications.
This is a minority of the overall market for database skills. Naturally, most of the database work is for administrators, whose job is primarily to maintain existing databases.
Do Relational Databases Work as an ERD Diagram?
No. A relational database is far more complicated than can be represented by ERD diagrams. Our touchstone concerning how relational databases work is the ERD diagram; the ERD diagramming does not do a good enough job of expressing what is going on in the DB itself.
ERD is just what we have today. It allows us to organize the tables and the fields and tables and the relationships in the data model. But it only captures a few dimensions of what the relational database does.
Are Modern Relational Databases Well Leveraged by Applications?
It occurred to me that there is some type of drop off between application sophistication and database sophistication. Most of the applications that I have evaluated don’t leverage enough of the capabilities of the RDBMS. And here, I am referring to an open source RDBMS, not Oracle, which has more functionality. Of course, that what I am developing my application for.
Let me give one example of an application that does an excellent job of leveraging what the database offers to see what I mean.
Oh, did you want something out of SAP BW? Well, roll up a sleeve. On SAP projects working in SAP BW is a bit like getting your blood drawn.
SAP came out with the idea of placing the BW on HANA to improve performance. But lost in the hoopla around HANA was that I had been using an application for years that was able to blow BW and DP (DP uses the same data workbench as BW) away in performance. I could load up as many attributes as I wanted and create any hierarchy that I wanted. I was and am still able to perform forecast testing without applying any of the complicated rules about data setup required in BW and DP. And my performance on a laptop was far higher than the company could attain with their more massive server.
Leveraging the Database
That is called leveraging the database. My hardware was tiny, and my database was open source. It slew the performance and usability of SAP. SAP BW that I competed against was on Oracle. So no problem with the database. The problem is that SAP BW was unable to take advantage of Oracle properly. This must be well known within Oracle’s database development group, but SAP is quite poor at developing applications that leverage Oracle’s database. SAP’s primary product is still ERP, and ERP is not an unusually heavy performance application. ERP’s most intensive process is running MRP and DRP.
And let us get into that topic a bit as the details are essential.
Is MRP Processing a Big Deal?
MRP was first developed to run on systems that were a pre-hard disk. That is right; the first MRP systems ran on tape-based systems!
“For those that are old enough, remember the introductory sequence to the 1970s TV show the 6 Million Dollar Man, where there is a brief shot of a 1970s tape storage system in action.”
So MRP is not only a “pre-advanced database” mathematical routine. It is a “pre random access” mathematical routine. And once again, I can run MRP faster on a laptop with a specialized application than huge companies can run MRP in SAP ECC.
So while David versus Goliath was a fable, it does exist in systems. And it exists when the designers of one “team” have an advantage over the designers of the other “team.”
**DRP is a method similar to MRP but less processing intensive as only stock transfers are created, and by that stage, the production process is complete.
Most of the rest of what ERP systems to is transaction processing (updating that financial account, posting goods issue, bing bing bing — small database updates, all day long).
Modern ERP systems have their origins in banking systems. After the military, banks were the next major area to be computerized. And of course, when it comes to financial transactions, the movement of money into accounts must be 100% reliable. The focus on transaction processing is reliability, not performance.
How the Applications Beat SAP’s BW
This is because the application was so well written and knew how to leverage the database. With all of its resources, SAP’s development team lacked the development capability of a small vendor with no more than five people working for them. CIO and ComputerWeekly don’t cover that kind of story — it’s terrible for their funding. If you want coverage in the major IT media outlets, don’t forget to bring a big wad of cash.
So that is just leveraging MySQL or PostgreSQL.
If, in the database community, there is a discussion and sentiment that goes something like this……
“Can you believe that that is all the application was able to leverage from what we have to offer?”
To this point, one of my colleagues responded…
“Yep. The programmers will only use what he knows. That’s why we make it transparent to the programmers. The DBA will analyze which tables should be in memory and do it.”
Being Misinformed by SAP
Concerning SAP, we are going through a period of excellent database miseducation courtesy of SAP. Much of what SAP says about databases is for competitive reasons and is not true.
“Oh, my database compresses.”
“Oh, I can run the database faster.”(“100,000 times faster” – Bill McDermott,“People will work between 10 and 10,000 faster because of HANA” – Steve Lucas.)(turns out not to be true, but was database performance a problem for SAP’s customers before they introduced HANA?), as covered in What is the Actual HANA Performance?
This was the problem when a company placed profit maximization before communicating what is true. Furthermore, what SAP is telling companies to focus on concerning databases is just plain wrong.
“Simplified data models lead to simplified business processes.”(covered in Does SAP S/4HANA Actually Have a Simplified Data Model & Faster Financial Reconciliation?)
There is far more exciting stuff in databases to emphasize. For example, multitenant functionality is fascinating. And all manner of decisions, with trade-offs to be made.
HANA’s Multitenancy?
Why doesn’t SAP emphasize HANA’s multitenancy capabilities? Because no software vendor would be stupid enough to develop with HANA.
**Actually, that is a question customers of SAP should ask. If HANA is so great, if HANA’s performance is so amazing, if its TCO is so low (lower than MySQL even?, so low that SAP pays you to use it?), why can’t you find software vendors that use HANA to develop anything? (Hint, to SAP customers, software vendors know more about software development than you do.)
How SAP Customizes its Messaging for Low Information Buyers
Let us face facts, HANA is for low information buyers, which means buyers that don’t work in software and which can be coerced and tricked into buying their database through their allegiance to SAP through career reasons, etc. That is those companies that allow themselves to be victimized……excuse me, I mean to write, “take guidance” from Deloitte or Accenture.
The upshot being, SAP does not emphasize multitenancy as multitenancy is functionality for software vendors. SAP can’t make money on the functionality, so who cares. One might expect an article on SAP as to why multitenancy is entirely overrated.
So Much False Information Being Spread
And the problem with having SAP spread so much false information about databases is that most people who repeat what SAP says have no idea if it is true. Many are..
- Just looking for an excellent job with health insurance, and they don’t rock the boat. They have families and do not have time to research things for themselves.
- Many will work in sales, whose only real job requirement regarding information is to relay what SAP says. If they don’t, they are in dereliction of their duty.
- Deloitte and Accenture are consulting arms of SAP and repeat what they say. They don’t care if it is true but has determined it is profit-maximizing to do so (see the case study of how the major SAP consulting companies humiliated themselves lending their support for SAP’s ludicrous Run Simple campaign as we covered in the article Is SAP’s Running Simple Real?)
- The IT media system employs mostly journalists with no technical background and no editorial leeway to question what SAP says (SAP is the customer of IT media, the reader is the audience and increasingly contributes nothing financially to the content development process.)
Therefore, the entire system is based on the elite opinion created by SAP, and then it is unthinkingly propagated throughout that system. These entities that what SAP says is true. Therefore, what SAP says is true forms the basis of what is true for many people and organizations.
Should One Process in the Application or the Database?
During this discussion, another colleague brought up the following point.
“Just an anecdote: at the beginning of this millennium I worked in an PL/SQL Oracle project. The whole business logic in PL/SQL stored procedures. Some UI logic in Oracle Forms. Our leading company SAP ABAP architect told us that letting the database do the job is a bad idea. Let the powerful highly scalable application server do the work for you. Load the database table records into an internal ABAP table, sort, sum, do work, etc. and write the result back to the database. Now SAP has its “Code Pushdown” and sells it like their “innovation” that business logic is (partly – when needed) running in the database layer. Great to know that I was working with 2017 bleeding edge technology 15 years ago.”
I thought this was a great anecdote.
Getting A Real Understanding of How SAP Formulates Technical Opinions
SAP does not make decisions based on technical reasons. So if they have all applications and no DB, then their “technical” opinion is that the application should do the work, and the DB just a container for data. When they develop a DB, they can use the DB for marketing reasons, and if by using stored procedures they have an excuse not to port to other DBs, they are in favor of doing the work in the DB!
SAP’s Flip Flop on Advanced Planning Systems
I witness this same flip-flop in the late 1990s. At that time, I was working for a supply chain planning vendor.
SAP’s position was that its customers should do all supply chain planning in its ERP system. Then SAP developed APO. And at that exact point, SAP began to extoll the virtues of performing planning outside of ERP.
It’s all about “what is good for us” and has zero to do with what is true technically!
The present economic theory holds that technical accuracy is a distant second to profit maximization. This means that the technology must follow profit maximization, and to not do so is a great insult to shareholders. And according to the US court system, there lying in commercial settings is not lying. It is “puffery,” as explained in the court decision of San Marin County versus Deloitte.
Conclusion
It is complicated to learn something from an entity that is completely lacking any integrity and merely intent on pushing you down a path that makes them money.
This is what taking information from SAP is like.
One must listen with extreme skepticism and verify every statement, particularly given SAP’s track record for accuracy, which we have evaluated in the article A Study into SAP’s Accuracy.