After one of my previous blogs posts on the SAP NetWeaver release simplification and my statements about backward compatibility of new NetWeaver releases, I got some questions about the following: If NetWeaver is backward compatible, can’t I just upgrade my SAP NetWeaver Application Server ABAP (which I will refer to as AS ABAP in the following), to get the latest in capabilities, but keep the same release of SAP Business Suite running on top of it without touching.
The answer is simple: In theory “yes”. In practice “no”.
“Why”, you will wonder, “is it like that?” and I want to try to give some explanation. Not excusing, of course.
If we look at an ERP system or any SAP Business Suite system, this is several hundred millions of lines of code. Complex code. Code that has evolved over many years. Enormously powerful, but also tons of code. The underlying “basis” system, the AS ABAP, consists of approx. 70 million lines of ABAP code itself plus another 14 million lines of code in 24.000 source files in “the kernel”, our C/C++ core runtime of Application Server ABAP. Also enormously powerful, but also a lot of code as you will agree.
“Beware of the Turing tarpit, where everything is possible but nothing of interest is easy.” [Alan J. Perlis]
Delivering an AS ABAP in a backward compatible mode, does not only mean that we haven’t changed the existing official interfaces and Application Programming Interfaces (API), but it means that all the functionality behaves in a “compatible” manner, i.e. one that does not create work on the customer side to keep their code or applications running. It’s ok to be faster than before, but not slower, it’s ok to consume less memory, but not more. It’s ok to be able to do more with the AS ABAP, but definitely not less. So we cannot, as an example, remove an ABAP statement, delete a transaction or remove a datatype from the data dictionary that was there before.
You may call it stupid, but it’s a matter of fact, of history, that a lot of functionality in AS ABAP is not officially put behind public APIs. Only late in the lifetime of ABAP we introduced a formal package and visibility concept. As a result existing code can access functionality using various means: it may use an official API, e.g. a BAPI, but that same code might also just directly go down to the database and read certain tables. Applications might have used data dictionary data types that they shouldn’t have used, but you can’t turn that back. Things happen. Not just in our code. But also in application code. And in code that our customers have written. There’s an estimate that of all the code in our SAP applications each of our customers on average has added 10% code on top in the form of custom development extensions (or sometimes modifications). All this code relies on public APIs, but it will also sometimes knowingly or unknowingly rely on implicit behavior or structure of code in the underlying system.
We cannot formally prove or enforce that our system — after another development cycle — is guaranteed to be backward compatible. We have guidelines and tools in place, restrictions in the system, that keep our developers from doing the obviously incompatible, but we cannot enforce that a certain piece of code behaves “incompatibly” in one way or the other afterwards.
I had a nice example just recently, how strange these things can sometimes be: our old SQL parser in the AS ABAP did — for some historic reason no one probably remembers any more — allow the tilde character (“∼”) in table names which was used for some obscure reason. The official documentation stated which names are formally okay, and that besides others the tilde character was not part of the legal set of characters. Nevertheless, the parser did allow the tilde character to pass without an error. Years passed. Now with HANA, we had to rewrite parts of the SQL parser in the ABAP compiler to enhance it for new HANA SQL features, and followed our own documentation for what was allowed characters. So the new parser returned an error message for a name with a tilde character in it. We didn’t figure it out in our own ABAP development system, because there were no such table names used. But when we put that AS ABAP underneath our internal Suite development landscape, we ran into sudden errors: because someone in Suite development, years ago, had used the tilde character and there were still three tables around with it… Now imagine we run into these issues not in our internal landscape, but at a customer with a productive system?
The point I want to make is the following: backward compatibility for a complex system like an AS ABAP, like for any other complex system as well, is a major undertaking. And it is like “zero defect software” an ambition to strive for, but it cannot be formally guaranteed. We have to test “backward compatibility” to some extent into the system before we ship. That’s why we run a vast amount of automated unit tests, manual tests, complex integration tests, upgrade tests, platform tests, etc. plus run our own Suite application development on top of our latest AS ABAP developments before it reaches any customer.
Like “zero defect code” or “no more bullshit”, “backward compatibility” of a complex system is an ambition, something to strive for, not something one can “per se” easily — or ever? — achieve. And let’s face it: It is sometimes not even desirable, to be 100% backward compatible, because it would mean to carry even faulty behavior of software around with you for decades.
“There are two ways to write error-free programs; only the third one works.” [Alan J. Perlis]
So when we say that NetWeaver develops backward-compatible, it’s the ambition we have and the decision to not change things incompatibly as a conscious step. And we do what can be done to make sure it’s the case.
The question for which SAP Business Suite versions we can officially release and support a certain version of the underlying AS ABAP version is — as I have outlined above — a matter of efforts required to validate we haven’t broken anything and confidence in our test results. We are obliged to — and feel confident that we can — make sure that the combinations of “technology” and “application” we release, have been properly validated and will work on the customer side. Just releasing an SAP NetWeaver Application Server version for any other SAP Business Suite release is simply not something we can reasonably do. Don’t forget that we have to provide validated upgrade paths for arbitrary customer start releases to our latest released SAP Business Suite version with a well-defined underlying SAP NetWeaver release. Any level of additional variability in here, results in an explosion of new combinations we have to test per database product (and version) per Operating System (and version) per SAP Business Suite start release (plus SP) etc. And the customer’s expectation is that “it just works smoothly” — no matter what.