What This Article Covers
- How SAP controls the language that others use about it.
- How competing vendors reduce the implied functionality of their own products in order to seem to fit better within SAP’s products.
- How SAP co-opts innovation that was never invented at SAP.
- How the media cow-tows to SAP and makes even SAP weaknesses seem up to snuff.
It is well-known that SAP is a very successful software company. However, what is not well-known about SAP is that they control the language that other vendors use when describing their products in relation to SAP, and that vendors that want to sell into SAP accounts have censored their language on their website. I increasingly notice this the more I see different vendors and how they alter their marketing message.
This is demonstrated in a number of ways. SAP has programs which co-opt the best of breed vendors. One well-known one was the xApp program. This program is largely a scam because there is no reason for the program to exist from a technical perspective, as mostly its a marketing construct. The vendors involved get mostly fake certifications that have no meaning on implementations and do not speed up the implementation. The best of breed vendors think they will be getting access to SAP’s customer base, but in fact, SAP dilutes the best of breed vendor’s message and actually begins to control the message. For more on the xApp program see this link.
SAP gets to co-opt other vendors and begins to influence them. That is one of the main points of not only the xApp program but of SAP’s certification program as well. This insubstantial nature of this program is described in this link.
Another benefit is that they attempt to analyze the application that they are partners with in order to reverse engineer the product. This is what clearly happened with SAP when they partnered with MCA Solutions a service parts planning vendor. SAP service parts planning application called SPP soon had many of the same functionalities in theory as MCA, although SAP never got them to work properly. This is described in this link.
How Partnerships with SAP Help Restrict Competition with SAP
While prior to having a relationship with SAP, vendors could be directly critical of SAP, after they have a relationship with SAP, they cannot take this approach, and must pitch their products not as competitive but as “complementary.” This comes across very clearly in the marketing documentation that is produced by vendors. I have noticed this for some time among many of the inventory optimization multi-echelon vendors, and I found it again at the website of a company that integrates to SAP. I have taken an example from a company’s website. I will leave the specific company out because I don’t mean to single them out, and it is really SAP that is to blame for creating an environment that requires companies to write in such a slavish manner.
When organizations integrate SAP with non-SAP systems it typically happens because the non-SAP application requires data that is managed within SAP® in order to deliver the expected value. Integrating to SAP is unfortunately not an easy task for a couple of reasons:
SAP’s data structures are deeply normalized. While this is a great strength for SAP as an ERP system it also means that data most people would consider basic objects ends up being scattered over numerous tables. Retrieving the data required by the external application therefore requires deep knowledge of the SAP data-model. Many organizations and 3rd party system providers do not have that knowledge.
The problem with the statement is that this does not fully explain SAP has such a high data overhead. Normalization is the following
“The process of organization data to minimize redundancy. The goal of normalization is to decompose relations in order to produce smaller, well structured relations. Normalization usually involves dividing large tables into smaller and less redundant tables.” – Wikipedia
This means that there are more tables, but each table is more efficient because it has fewer relationships within the table and more between various tables. This speeds searching through tables. However, many vendors normalize their application database. The real issue with SAP’s data layer is not that it is normalized, but that:
- It is poorly documented. SAP does not publish its database schema.
- SAP’s transactions for dealing with tables, such as SE16 and SE16n, are just single table views, and make understanding the now data relates to other tables a major problem.
- Unlike the vast majority of vendors, SAP’s tables and fields have unintelligible names. Several well-known tables are the MARC and VBAK. The fields are named in the same way.
- Any field in SAP can be interrogated by selecting the technical help. However, the many fields point not to actual tables, but to virtual tables or what SAP calls “structures.” Finding a field in a structure is essentially a dead-end.
- SAP cannot be connected to any standard relational database tool such as TOAD or Navicat. This means that only SAP transactions can be used to get to the SAP data. However, SAP’s tools are extremely weak, and inefficient for even experienced data resources to use. All other vendors in the supply chain space do not require the use of proprietary tools and therefore are much efficient when it comes to data management.
False Statements Made to Protect SAP
Therefore, the statement made by the vendor regarding normalization being the reason why SAP’s data backend is difficult to deal with has truly nothing to do with anything. SAP has problems with any data backend that it creates, regardless whether it is ERP (which the vendor here is referring to), or APO or BW. This is described in this article, and has nothing to do with normalization of data. It has to do with poor software design.
The next quote briefly touches on SAP’s enormously inefficient integration approach. As SAP is the only vendor to wrap its data backend in such opaque complexity it is the most difficult application to integrate to. The most popular way to integrate to it has been for SAP to push out and IDOC, which is a hierarchical file format which must be parsed with a transformation language such as UNIX’s Awk. Another way is to use a remote function call (RFC), which have to be coded, and in my experience have demonstrated a number of performance problems. Let us see how this compliant vendor soft peddles SAP’s integration weaknesses.
“To control access to the SAP® database SAP® has developed several proprietary integration technologies. These technologies do provide a more streamlined view of the underlying data complexities, but they also introduce new technology barriers that typically require costly development and 3rd party integration tools to overcome. The objects exposed by these integration technologies often don’t provide access to all the data required to resolve an integration challenge. Many solutions therefore end up looking like a mix of technologies and approaches resulting in long-term sustainability issues.”
Notice they phrasing here has to pay homage to what is, in fact, a terrible design. None of the “proprietary integration technologies” that SAP has created work very well. The section highlighted in blue builds on a point that does not exist. The proprietary integration technologies don’t work well, so the following sentence is, therefore, a problem because its assumption is not true. The problem with one of the major SAP integration technologies is covered here.
Secondly, SAP does not want them to work very well because they do not want clients connecting the best of breed applications to their ERP system. Instead, they want to companies to buy other SAP products that compete with the best of breed vendors, that cannot compete with best of breed vendors. A major strategy of SAP for several decades has been to direct clients to SAP products on the basis that integration is really difficult. Integration can be difficult, but nowhere is it more difficult than with SAP.
As for the rest of the paragraph, there is some definite beating around the bush, although there are some negative comments made, which is listed in blue. Essentially SAP’s preferred integration is no integration. However, I guess some excuse has to be made up. It’s hard to get a partnership with SAP if you declare their data approach an unmitigated design disaster that may have been put in place to prevent integration to best of breed vendors, and is probably a violations the spirit if not the letter of US Anti Trust law (SAP’s relationship with vendors where vendors pay them 70% and are on the SAP pricing list seems to harken back to Standard Oil’s business practices.).
A Culture of False Information
The vendor information that is being provided on their website with respect to SAP is false and incredibly deferential to SAP. Why does this vendor have to write in this way? This because every word on this page had to be approved by SAP. As soon as a vendor develops a partnership with SAP, freedom of speech is out the window. However, many vendors need the certifications in order to put prospective clients at ease. Interestingly, all the SAP certifications mean very little on a project and are primarily marketing hyperbole. They don’t do much testing at all. SAP
Why is this “®” required every time the term SAP is mentioned? This is not part of copyright law. A company name does not need to have “®” associated with it. Can you imagine what this would look like if every time a company was mentioned it was necessary to add the “®” it would be ludicrous? This quote is at the bottom of the page.
SAP® is a registered trademark of SAP AG, Germany
That is nice. Every company registers is trademark, therefore the fact that SAP did so is not surprising and not particularly relevant. However, it does not follow that “®” has to be used. This is again more slavishness to SAP. This is no doubt at the command of SAP. What is amazing is there are companies like Plan4Demand that have used material from this site without providing any reference of where they obtained it, but SAP gets unnecessary “®”‘s added in this way. But let us move to the content of the quotation.
When one software company is so powerful and so aggressively reduces the independence of other software vendors, it is a major issue to be discussed from a regulatory perspective. There are many practices that need to be investigated by the Federal Trade Commission. One vendor cannot have the power to approve other vendors. However, that is what is happening with SAP.