It’s six days to go. Six days. I am getting excited. Six days until I will open spring season.

Today I open the traditional ceremony by watching my all-time favorite movie again: The Graduate. Young Dustin Hoffman’s debut from 1967. I have watched this movie a hundred times in the meantime, but I can always enjoy it again: The dialogs are hilarious, the whole visual appeal of the movie is timeless and the cuts are just brilliant! Anne Bancroft, Katharine Ross and Dustin Hoffman are awesome… The soundtrack from Simon and Garfunkel is a classic!

I first watched the movie back then when I was still in school and later when I went to university. They played it regularly in a cult movie theater in Heidelberg. That’s when I fell in love with something else in this movie: Dustin Hoffman’s little red Italian car: An Alfa Romeo “Duetto” Spider! Funny how Benjamin (Dustin Hoffman) is following his true love Elaine throughout California in the movie, riding through beautiful Californian scenery, crossing Bay Bridge in San Francisco, making his way from Los Angeles to San Francisco, to Berkeley, trying to gain her love…

While being at university in Karlsruhe, I had a night-time freelancer programming job at a startup company in the middle of nowhere, Germany: A company called SAP, located in Max-Planck-Straße, Walldorf, that at the time had an already impressive number of employees: around 500. While most of my colleagues at the time were still working on a mainframe system called R/2 and there were just first steps made towards a client/server-based solution called R/3, I was the “PC guru” who was programming frontend applications to visualize and provide drag&drop modification of org charts in the R/2 and later R/3-based HR application. As you can see, the company was already back then visionary enough to identify the constant need for a tool to help companies to flexibly reorganize 😉

2013-03-26_21-32-40Anyhow, it happened that a colleague of mine at the time was driving one of the successor models of this Alfa Romeo Duetto Spiders: A black one, with some fashionable 80’s plastic spoiler that Pinin Farina must have designed onto his otherwise perfect design in a moment of total derangement. But in the end, it was the car I needed to get and when the colleague decided to sell it, I become the lucky owner of an Alfa Romeo Spider! Who cared about this plastic spoiler… That’s how it happened that in the following 12 months, you could see happy me and a friend of mine, both Computer Science students at University Karlsruhe at the time, ride with a big smile hammered into their face, wind blowing around their head with the top opened, to Karlsruhe every morning to follow some lectures at University, and back to Walldorf in the afternoon to start their second life as freelance programmers at a company called SAP over night… We had a great time back then…

2013-03-18_13-55-05The fun lasted 18 months roughly, until a strange and seriously concerning rumble from the rear axle convinced me that Italian convertables are perhaps not something that a Computer Science student with just a nighttime job should really invest into. So I sold the car before it became an expensive investment ruin.

But the dream about an Alfa Romeo Duetto Spider, the original from the 1967-69 period, the one with the round tail, nicknamed “Osso Di Sepia”, remained with me for years. Like the tradition to watch The Graduate over and over again whenever it was played in the movie theater in Heidelberg…

Finally, in 2002 I decided to go get a Duetto. I started to browse various oldtimer forums, online used car sites and travelled Germany in search for my Alfa Romeo Spider. After quite a number of disappointments and learnings, I made the one out. My Duetto. A 1969 Alfa Romeo 1750 Spider. Born 1969. White. Reasonable condition. Some minor things to fix, but otherwise original and in good shape. A re-important from the US. It seemed we had been in search for each other. And there we finally got together… Lol!

IMG_1695And now, every year since then, there is this tradition of me watching “The Graduate” again a few days prior to April 1st, when my Alfa Romeo Duetto gets out of its garage after winter. She gets hibernated in October every year, covered with a blanket and on April 1st, no matter what weather the day happens to bring, I carefully lift the blanket covering her, send a prayer towards heaven that oxidation has had shown empathy with us again this winter and there’s not just a small pile of rust on the ground left of her, and after some de-hibernation and cosmetics, we go for our first rendezvous of the year… The top open, the sun above us — keep your fingers crossed –, the wind around us and attitude clearly being that this will be our year again… Get out of our way, ’cause here we come… The only living boy in

Six days to go. Six days…

lol 🙂

… but a huge step for mankind 🙂

NetWeaver 7.40 will finally — after decades of desperate but hopeful waiting of our loyal developer community — bring curly brackets to ABAP! At least in one area: Core Data Services (CDS).

If you don’t believe me, here’s the proof as seen in my latest Product Review meeting. Core Data Services (CDS) as implemented both in SAP Hana itself as well as in the application servers like ABAP and RDL (River Definition Language) will provide easy and efficient means to interact with HANA data embedded into your programming language of choice. Including curly brackets! You will love it! Believe me! I am so excited, I can probably not sleep this night… Curly brackets… Boy… That’s unbelievable… Ha… Curly brackets…


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]

Men at workDelivering 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.

That’s why.

I quite often get questions on what’s happening with our SAP NetWeaver platform and what direction it is taking. While I could easily spend an hour on elaborating this in detail, let’s not bore you to death but rather try to give you the quick elevator pitch.

First of all, it is important to understand that we have more than 70.000 productively used SAP NetWeaver systems out there with our customers. Around half of those are underlying applications infrastructure for our SAP Business Suite solution, the other half is “standalone” NetWeaver hubs like SAP NetWeaver Portal or SAP NetWeaver Process Integration. So our customers are not only using SAP NetWeaver to run their mission-critical core applications, but also to extend and integrate those solutions with both SAP and non-SAP IT landscapes for processes and their end users.

It is clear that SAP NetWeaver, our core technology platform, is therefore absolutely strategic to the business of our customers and partners. And so it is for SAP!

As a consequence, we keep investing into this core technology platform. Main investment areas are of course the further improvement of the capabilities of the NetWeaver components in detail, but specific efforts flow into the areas of further simplifications in system landscape management, e.g. through our SAP NetWeaver Landscape Virtualization Management (LVM) solution, extensive integration into SAP Solution Manager for end-to-end solution management, business downtime optimization through e.g. Near Zero Downtime Maintenance procedures, usability enhancements like SAP UI5, NetWeaver Business Client with Sidepanel and many many more.

One of the clear constraints under which we keep evolving this core SAP NetWeaver infrastructure is strictly backward compatibility. As I had written in one of my prior blog posts, we have consolidated the various NetWeaver release lines into a single one (starting with the merged NW 7.03 and 7.31 ABAP lines) and will keep shipping additional “Enhancement Packages” or releases in a compatible, “non-disruptive” manner in sync with SAP Business Suite.

Slide03At the same time, our technology portfolio has grown beyond the core SAP NetWeaver solution bundle over the past years: SAP NetWeaver Gateway, SAP NetWeaver Identity Managament, SAP NetWeaver Single-Sign On and others carry the NetWeaver brand but are not per se part of the solution bundle and it’s release cycle.

We’ve been harmonizing the independent schedules, but currently they are a bit shorter than those of the NetWeaver bundle to allow us to bring new capabilities to market quicker in these younger ones of our NetWeaver products.

While we keep investing significantly into the classical SAP NetWeaver core platform as described above, we have to take into consideration that the whole IT industry is currently experiencing major changes, driven by a number of mega trends. Most prominent within those trends are the areas of Big Data, of Cloud computing and Mobile. These topics are reflected in our innovative extensions into the realm of SAP HANA, our in-memory, column-store database platform, our SAP NetWeaver Cloud platform (aka NEO or HANA Cloud Platform) and various extensions into the Mobile platform space.

In the area of SAP HANA, our blazingly fast completely in-memory, column-store database, we’re evolving NetWeaver along three directions:


First, we port all of our NetWeaver offerings to HANA as a fully standard-compliant SQL database. We’ve done that for ABAP already, as it is used in SAP Business Warehouse on HANA since May 2012. But we’re also porting our JEE engine and all the NetWeaver hubs to HANA and will make those available to the market during the course of the next months.

Second, we are optimizing our SAP NetWeaver portfolio by taking specific advantage of the unbelievable speed of SAP HANA. One obvious example is our Business Rules engine, which we have re-implemented in HANA itself to bring the rules execution as close to the data itself as possible and therefore be able to reduce evaluation that otherwise have taken hours down to mere seconds. Imagine what these factors of performance improvements mean e.g. to customer segmentation for marketing purposes or data analysis in the area fraud detection.


Finally, we are bringing completely new capabilities to our SAP NetWeaver platform, like we did with SAP Operational Process Intelligence,  the newest kid on our SAP NetWeaver Process Orchestration portfoilo, that allows Lines of Business to monitor and react in realtime to custom defined KPIs on processes that run across a complex system landscape, whether it is implicit processes running through many users in an ERP system, or classic Workflow processes or business processes executed in our BPM solution. This solution wouldn’t be possible without the power of SAP HANA.


What you need to definitely check out — and where it is actually extremely easy to get your hands dirty with — is our SAP NetWeaver Cloud platform. It is our open and standards-based development platform-as-a-service for Java developers with the ability to plug in additional frameworks like node.js or php in the near future. It can furthermore host a variety of contemporary, standard programming models for enterprise class application development like Spring, Ruby and others. You can use it to extend your existing business processes quickly and easily into the cloud with a compelling mobile experience, use it as an extension platform to, for example, SuccessFactors solutions, or build brand new applications from scratch to meet new business needs. You take care of your application, SAP takes care the rest!

We now offer free, unlimited developer licenses and you can easily sign-up online at our Dev Center in the SAP Community Network. Once you’ve update your Eclipse Dev Environment with the NW Cloud tools from our Eclipse Update Site, you’ll have your first hello world app developed, deployed and up and running within 5 minutes max. Promised!

SAP NetWeaver Cloud offers native integration with SAP and other back-end applications, I comes as a standards-based development and run-time environment, so there is no vendor lock-in and no steep learning curve for developers. It offers Portal capabilities through SAP NetWeaver Cloud Portal for quickly building appealing, mobile-enabled websites that connect applications, reports, and unstructured content from various sources. With its federated Identity Management and Single-Sign On solution you can seamlessly access applications, even across on-premise and cloud. And last, but not least, it gives you access to the speed and scale of in-memory computing technology with SAP HANA! All of this running in the SAP Cloud, managed by SAP for you!
And we are adding new services every quarter. The next ones to expect are Integration-as-Service, which is the cloud extension of our SAP NetWeaver Process Integration platform. And “Mobility-as-a-Service” that our colleagues from the SAP Mobile Platform are developing together with us.


Mobility“Mobility-as-a-Service” comes with the official name SAP Mobile Platform Cloud Edition. It naturally complements our on-premise SAP Mobile Platform. We plan to make it available within 2013. It allows you to extend your on-premise business processes and solutions via our Cloud infrastructure to mobile devices of various sorts and form factors for a certain set of mobile applications. It supports the on-boarding of users and their devices, helps you manage your mobile applications and their access rights, and securely connects them with the processes in your on-premise backend if needed.

Two further important examples on how we are evolving SAP NetWeaver into the mobile space are SAP NetWeaver Gateway, which allows you to access to business processes and data running in the SAP Business Suite using standard protocols http(s), REST and OData. With those, it’s extremely easy and efficient to access existing backend functionality from mobile applications, whether natively coded in Google Android or Apple iOS or whether you’re using one of the many mobile HTML5-based SDKs. One of which is SAP UI5.

SAP UI5 is our standards-based HTML5 control library. It supports not only mobile devices running e.g. Android or iOS, smartphones or tablets, but also all major desktop browsers. It comes with a rich set of fully customizable UI controls, from simple buttons to complex dynamic layout containers or charts for analytical data. It is based on jQuery and can be extended using custom-written or 3rd party UI control libraries.

So this was thought to give you just a quick glimpse into what is currently happening with SAP NetWeaver and what the directions are into which we are taking things…

Bing, 1410th floor. Are we there already??? 😉

P.S.: All the usual disclaimers apply…