Ben, what are you doing?Mr. Braddock: Ben, what are you doing?
Benjamin: Well, I would say that I’m just drifting. Here in the pool.
Mr. Braddock: Why?
Benjamin: Well, it’s very comfortable just to drift here.
Mr. Braddock: Have you thought about graduate school?
Benjamin: No.
Mr. Braddock: Would you mind telling me then what those four years of college were for? What was the point of all that hard work?
Benjamin: You got me.

We all experience it many times every single day. With italian cars that just won’t start in the morning. With Exchange Calendar appointments that simply disappear. With mobile apps that just won’t connect to the Internet when we need them. With auto-correct features in email clients that changed some words in your email in a career-bending or relationship-ending fashion without you noticing before you pressed the send button.

What I refer to is the bitchy randomness at which technology failures light up our days. Light up in flames. And like with all things people love from the “consumer space”, the expectations rise also towards the so-called “enterprise space” to follow accordingly. That’s commonly referred to as “consumerization of IT“.

Over the past months and years, we got painfully aware that even in ABAP the developer community has become comfortable with the status quo, complacent almost as to how easy and predictable it is to quickly code a new application to serve your employer’s or contractor’s needs. Far too easy, we believe. We all feel that it has to remain a certain science, wizardry, black magic to understand how a computer program actually works. And it has to feel arbitrary to some extent. Like bringing up your kids.

My team got notice of this burning issue already some months ago, but it took us a while to build up the necessary sense of urgency around it. And luckily, with Design Thinking, we got the tools at hand to really confront the problem heads-on. How could we bring the random malice of the consumer space experience to enterprise computing? What we came up with is simple but effective. As always.

After building and pushing around a fancy straw prototype of the solution in a Design Thinking session, we decided to introduce the COME FROM statement in ABAP. It contrasts with the GOTO statement, which for good reason has been considered as an approach too naive to effectively confuse programmers by acclaimed computer science legend Edsger W. Dijkstra already in 1968, as it does not impact the control flow of a program by telling where to jump to in execution, but rather tells where to come from whenever program execution happens to pass the given source code location. It started as a notion, but we quickly turned it into an ingenious idea and then into a brilliant concept. In particular if one looks at the additional attributes that one can add to the “come from” statement:

COME FROM [WITH PROBABILITY <expression> ].
where <expression> can be any valid ABAP expression yielding a floating point value between 0 and 1, or whatever else at which the execution is not determined at all.

As common sense implies, the COME FROM statement will be executed with the given probability, resulting in the programm execution continuing in the first statement following the COME FROM statement or continuing at the statement at the <source code location>.

Without thinking for too long, even the most junior developer will realize what enormous excitement such statements can bring to otherwise trivially boring code.

In a relentless effort to bring unnecessary reduncancy into the set of ABAP language features, we have also decided to introduce a new statement for execution blocks:

SKIP. <statements> END SKIP [WITH PROBABILITY <expression>].

The careful observer will have recognized our villainous brilliance to move the probability expression to the end of the SKIP execution block in order to further reduce code readability.

We plan to introduce these new ABAP language features with SAP NetWeaver 7.4 after some more intensive validation with customers.

With SAP NetWeaver 7.5 we will then provide a set of new capabilities in the ABAP development tools to improve the effectiveness of the new statements above.
First, we will introduce what we call “progressive obscurity” in the “ABAP for Eclipse” editor: with this feature you can — based on personalization of your Eclipse settings — determine whether the editor shows or hides the SKIP and COME FROM statements from display. This adds enormously to the fun during professional code review sessions. We are also testing whether randomly hiding normal statements outside of SKIP blocks could further help to confuse code reviewers.
Second, we will add support for the above statements in the ABAP Debugger and the ABAP profiler, which will be enhanced with predictive code execution capabilities built right into the tools themselves interfering with the underlying runtime Virtual Machines.

We are also working on bringing the above concepts into other programming languages: River Definition Language (RDL) is a natural candidate of choice. But also for Java we are pushing a proposal into the Java Community Process (RCP) to embed these capabilities into Java 8. For C/C++ we have started discussions with the ANSI committee. The ECMA committee has been approached by us to embed the concepts into ECMAScript/JavaScript and the major browser vendors have been invited already to a workshop in Walldorf. If we do something, we do it right.

Obviously, all of this is only a stop gap solution to bridge the time until the probabilistic behavior has been pushed further down the stack into the hardware itself. We have started to try to convince major CPU/MPU builders like Intel and AMD to add the above features to their hardware designs yielding utmost performance in randomness.

We understand that such a hardware driven approach will take some time to be ubiquitously available in all IT landscapes. We have therefore triggered efforts with Operating System makers to provide software solutions to the market that already today bring the benefits of random behaviour to end users. Solutions include TCP/IP drivers, DNS and DHCP servers, network domain login modules, Exchange server modules and file system drivers that will show arbitrary failure and outage behavior.

A renowned IT analyst company, that wants to remain unnamed for unspecified reason, has estimated the 2017 market for such solutions to exceed 37 billion US$ in total. While we consider the market significant, we have certain concerns though how much of this market we can actually tap into with a standard software solution, as corporate IT departments already today seem to have deployed partial solutions for random infrastructure behavior. At least that’s what we deducted from end user reports we’ve evaluated.

Patents are of course pending.

Hope is at the horizon. The days of waiting are numbered. With probability 0.5.

All will be fine

cancelled...I am stuck here in Germany due to the cold — we have 0 degrees Celsius — and the snow which triggered havoc at the Frankfurt airport, leading to the cancellation of my flight out to Israel. Both flights, actually. And in Tel Aviv, where I planned to participate in the Tel Aviv 2013 Half Marathon on Friday, they cancelled the Marathon event because of the heat — they expect 30 degrees Celsius and above… Isn’t that ironic?

Life has a funny way of sneaking up on you sometimes…

San Francisco. The City. I love her.

Heading back from SFO to Germany after four days of packed schedule with colleagues in our SAP Labs in Palo Alto. I always enjoy being there. Taking a deep breath of Pacific Ocean breeze and Silicon Valley buzz. Trying to inhale as much as possible. Filling lungs and mind. Then eagerly holding my breath to preserve impressions and insights for “back home” in corporate headquarter.

What particularly sticks with me this time and keeps me thinking is our SAP developer ecosystem. I had a meeting with our Developer Community colleagues discussing how we can extend the reach of our technology platform offering beyond our current developer community? Is our Open Source and open standards driven approach these days paying off? How can we take our existing 2 million developers ecosystem with us into the new technologies like HANA, Cloud and Mobile? What are the new skills we need to help developers to acquire step by step? What do we need to learn from them? How can we become attractive for the “scripting kids” and their main ask: “What’s your API”?

For a company that made almost half of its new software license revenue last year – a roughly 2.1 billion euro business – in technology related products, we should be better known for them. For with more than 60% of the world’s business transactions running through SAP solutions, the underlying technology of those solutions is obviously highly strategic for a vibrant partner ecosystem and constantly growing customer base.

It’s time that the world recognizes that we’re meanwhile much more than just an ERP company. And with SAP HANA and our offerings in Analytics, Cloud and Mobile that should be obvious. We’ve come a long way. It’s not that same SAP from the past any more. It’s a new SAP. For sure inside. For sure for our customers and partners. And we need to turn this into a new SAP for developers as well…

While the flight info system suggests that LH455 hangs somewhere in the air at 30.000 feet over the Atlantic, I am still hanging on to San Francisco in my mind. Haven’t really left the City yet as it seems. She always leaves a mark…

20130308-111306.jpg