Ben, this whole idea sounds pretty half-baked.

Mr. Braddock: Ben, this whole idea sounds pretty half-baked.
Benjamin: Oh, it’s not. It’s completely baked.

You got me.

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.

Tom Gilb (Agilist) about large scale

“If you don’t know what you are doing, don’t do it on a large scale.”

The waiting has an end

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.

I just want to say one word to you.

Mr. McGuire: I just want to say one word to you. Just one word.
Benjamin: Yes, sir.
Mr. McGuire: Are you listening?
Benjamin: Yes, I am.
Mr. McGuire: Plastics.
Benjamin: Exactly how do you mean?

Isn’t it ironic?

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…

What’s your API???

You meet them everywhere: At “hackathlon” events, at conferences, in developer forums, at StarBucks, even in the supermarket in front of the cereals and before you can even address them with “Son, why don’t you come over to our side of the platform?” they pull out their light saber, wave the shining and humming blade fiercly in front of your nose and shoot the probing question at you: “Father, what’s your API???”.

This is them. The next generation of programmers. The “scripting kids”. The developers that rule the mobile apps space. The ones that are quick and nimble if it comes to combining the latest in mobile app development — whether it’s native Android or iOS, whether it is HTML5, CSS and JavaScript doesn’t matter — with services provided by the Facebooks, the Twitters, the Amazons of the world, exposed as Application Programming Interfaces, or “API”s. They know that stuff like the inside of their pocket and if not they know how to figure it out quickly on the Web. They have their favorite server-side platform, whether it’s php, Ruby or node.js — it doesn’t matter. Some might even remember Java. They are fluent on these platforms and there is little interest in switching. What for? You glue your mobile app together using your favorite technology, which is defined by you being super productive in it plus it being somewhat at the forefront of being hip in the community — hey, that’s part of the fun.

So, “what’s your API??”

If we — SAP — want to attract a larger developer community to our technology, then clearly we need to address the needs of this generation of mobile application developers. It’s many of them. And they are active in a highly attractive and massively growing space: mobile apps.

And I believe there are 3 aspects of this that we need to tackle:

1. We need to enable our own platform, i.e. SAP NetWeaver Cloud (aka HANA Cloud Platform), at the relevant level with APIs itself. A simple example is management of the platform itself (e.g. deploy, start, stop), but also services like monitoring, configuration etc. are obvious examples.
2. We need to make it easy for applications and services built by our partners and customers on top of our NetWeaver Cloud platform, to API-enable their offering. Our customers own highly relevant business content and services and can expose these offerings easily via our NetWeaver Cloud platform to e.g. mobile consumption. This is where the highly valuable business content for a developer community enters the scene.
3. We should provide the means to manage those APIs on top of our platform, make it easy to document, find, consume, monitor or meter those APIs. This should come as a service of the platform itself.

This morning, I had my monthly takt-end “Product Review meeting, a day-long meeting where my management team and myself take a look at the aggregated sprint results of our various products in development. We do Scrum in a very systematic way in my organization with around 2000 developers spread around the world. The Product Review takes a full day and constitutes the only “status update” about products and programs that I ask my organization to come up with. And that’s enough, by the way.
Today, we took a look at the current status of Gateway-As-A-Service, which is the SAP NetWeaver Cloud-based incarnation of our SAP NetWeaver Gateway product, a gateway that exposes business functionality implemented in our SAP Business Suite and accessible via Remote Function Calls (RFC), Business APIs (BAPIs), Dynpro screens (via “screen scraping”) and various other programming frameworks, in a standard-compliant manner based on REST and OData protocols (serialized as JSON if needed). So you can easily consume any of the business functionality in e.g. your mobile app in a simple, coherent and standard-compliant way. I am totally excited about the fact that soon our customers and partners will be able to expose any business functionality in the SAP Business Suite to the Internet and mobile applications without even installing an SAP NetWeaver Gateway in their corporate infrastructure, but can do so by simply connecting securely via our Cloud platform where we handle all the infrastructure provisioning. That’s a major step towards getting to those APIs we talked about above. Not the full story about APIs yet, but I am confident we’re getting closer every day…

I am very confident — I am convinced — that we are able to handle all the technical challenges at hand. The bigger challenges we will have to address are the following:

1. Bridge — or smooth out — the inherent friction between expectations of extremely straightforward and simple access to business functionality on the consumption side, i.e. for example in the mobile apps space, compared to the variability and complexity of underlying business processes supported in the backend business processes. This will be harder the more “generic” the APIs exposed will be — the intrinsic problem of customizable standard software that can potentially do every variant of a certain process –, and it may be simpler the more specific the use case will be — e.g. if one of our platform customers exposes a specific service to the Internet, it can be completely “hardened out”, resulting in much easier APIs. So perhaps we should rather focus on making it easy to “harden” out specific versions of APIs than trying to expose everything “generically”.
2. Solve the business model underlying the API consumption model: It’s great to expose APIs technically, but for sure there need viability and monetization considerations to be taken into account — not just for SAP as a platform provider, but in particular for our customers and partners willing to expose APIs for their services on top of the platform.     

So all of this comes with considerable challenges, but the opportunities opened up by such an approach of API level access to the platform and SAP customers’ business use cases are enormous.

“Success is where preparation and opportunity meet.” [Bobby Unser]

Any thoughts out there on this?

Here we go

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…

Here we are

Ex-Developer, Former-Software-Architect, Forced-Emmigrant-Into-Management, Passionate-Marathoner, Wanna-Be-Cosmonaut, Ever-Pending-Book-Author, Addicted-San-Francisco-Lover

Officially Executive Vice President at SAP, Products & Innovation Technology

Views expressed are not necessarily SAP’s, sometimes not even mine.