“If you don’t know what you are doing, don’t do it on a large scale.”
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
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.
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.
Often it is the simple things in life that bring you most happiness and joy.
That’s why we have worked hard over the past two SAP NetWeaver releases or Enhancement Packages (which are for technology effectively minor releases in the terminology of the rest of the world as we do not support switchable functionality like the SAP Business Suite) to simplify the parallel code lines and version numbers of SAP NetWeaver.
And since the most simple approach is a single code line, we’ve simply gone for that one.
So while in the past, we had two parallel development code lines of our NetWeaver platform: one underlying the SAP Business Suite as “stable core” applications infrastructure, e.g. the Application Server ABAP, labeled version 7.0x (e.g. 7.00, 7.01, 7.02, you got it), and a separate one for our “faster innovation cycle” standalone SAP NetWeaver “hubs” like SAP NetWeaver Portal or SAP NetWeaver Process Orchestration, labeled version 7.1, 7.2, 7.3 and 7.31 respectively. Confused? Don’t worry! You are not alone. And there’s more: For our on-demand Business ByDesign solution we had started to build a multi-tenant, HANA-optimized version of our Application Server ABAP, internally labeled 8.0x. In parallel. Again a separate code line.
“I’m confused… No, wait… Maybe I’m not…” [Unknown]
Now, luckily, we got the message from our customers (and we even got confused internally from time to time) and simplified things again: with SAP NetWeaver 7.03 (underlying SAP Business Suite 7 Enhancement Package 6) and SAP NetWeaver 7.31 hubs, we have a single, identical ABAP application server again! We merged the two 7.0x and 7.x code lines into a single one. And with SAP NetWeaver 7.4 — the next backward compatible Enhancement Package or minor release version of this combined 7.0x/7.x code line, you will even get major improvements ported back from our on-demand operations optimized ABAP server version. Plus, to complete the picture, you will get optimized support for SAP Hana with it as well. All in one single code line, that we will continue to evolve in a backward compatible manner. And in sync with the SAP Business Suite release cycle.
Our release numbers will reflect this simplicity in the future: 7.4, 7.5, 7.6, …Got it?
Actually, just in case you haven’t recognized it yet: it says 7.x all the time. Emphasis being on 7. So SAP NetWeaver will remain backward compatible.
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…
“Life is far too important a thing ever to talk seriously about.”
The alarm clock rings you out of bed at 5am, you quickly shower, shave and get your luggage ready to leave the house, when you realize — it started to snow again! Arggg! Should have checked before… Still, when you leave it’s still plenty of time to get to the airport and catch your flight to Tel Aviv… Until you end up in this traffic jam that has been piling up after a truck accident and police closing the whole Autobahn for 2 hours… OK, that’s it, let’s try to catch the next flight this evening…
This is DKOM week for SAP! Our world-wide internal Developer KickOff Meeting (DKOM), with local events in all major development labs around the world, offering our developers a chance to network and hear for two days what’s relevant for them this year.
I am excited to fly out to Israel today to visit Ra’anana, which is the town where our Lab is located, close to Tel Aviv. Mickey Steiner, our Lab Managing Director, and his leadership team have invited me for giving the keynote presentation at our internal Developer Kickoff Meeting 2013 at SAP Labs Israel. It’s the third year in a row, so I guess it now turns into a tradition…
I always enjoy visiting Israel. I like meeting and hanging out with our colleagues there. I always feel warmly welcomed. The folks in our Lab are true geeks and their energy and enthusiasm around innovation and software engineering is always inspiring! And it’s always an excellent opportunity to also meet my teams there: Besides other topics, major development of SAP NetWeaver Gateway happens in Ra’anana, in particular the Gateway consumption tools in Microsoft Visual Studio and for Apple Xcode.
Our Ra’anana Lab is a great place to be and a great place for me to share what’s going on in our technology platform at SAP from a strategic perspective and what we’re up to in 2013 from a priorities perspective. The good thing is, it’s pretty stable and consistent in terms of major direction and trends: So my keynote will be about the way how HANA revolutionizes solutions we’re offering, how Cloud enables unprecedented speed in delivering new capabilities — and receiving unfiltered feedback about them — and how mobile radically changes the user experience you’re used to in SAP solutions. What is even better, we’re seeing major progress along all these three dimensions and released products prove that we’re not just visionary, but that we also have an execution engine in place to turn these ambitions into reality quickly and effectively these days.
Did you know, btw, that our SAP NetWeaver Cloud Portal — powered by SAP NetWeaver Cloud (aka HANA Cloud Platform) — has been invented and developed at SAP Labs Israel? We count more than 500 active sites already and have more than 1200 trial accounts registered. It’s already fully designed and optimized for both desktop and mobile device usage and allows you to not only mash up new portal sites with applications, reports or unstructured content, but also to expose classical SAP NetWeaver Portal content from your on-premise landscape via the Cloud in a simple and secure way. And there are more than 12.500 such SAP NetWeaver Portals live at our customers today… So SAP NetWeaver Cloud Portal is an excellent example how we’re not simply taking our existing NetWeaver “hubs” and put them into the Cloud as appliance, but how we are redesigning our Cloud offerings from scratch to optimally fit the new use cases, but make sure to create the link to the existing on-premise NetWeaver infrastructure. The same holds true for SAP NetWeaver Cloud Integration, our cloud extension to on-premise SAP NetWeaver Process Integration and SAP NetWeaver Business Process Management, where you will be able to reuse mappings or process models across classical on-premise and cloud solution. Or take Mobility… That’s the strategy we’re following.
It for sure will be a fun week ahead of me…
So now let’s see whether I finally make it to my flight to Tel Aviv in time…
“If you want to make God laugh, tell him about your plans.” [Woody Allen]
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???”.
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:
- 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.
- 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.
- 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:
- 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”.
- 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?
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…
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.