Skip to Content
Author's profile photo DJ Adams

Monday morning thoughts: milestones

In this post, I look back at changes and developments that I consider milestones in SAP’s technology history, and muse on some of the developments today that we’ll consider milestones in the future.

Image result for manchester milestone

A milestone on the A57, just outside of Manchester (Wikimedia commons).

I’ve been fortunate enough to have lived and worked through more than three decades of SAP technology.

Seismic changes

In that time, I’ve seen seismic changes. Here are three of those that immediately come to mind:

  • the move from the use of hierarchical databases to relational databases – I remember the move from the database management component of IBM’s Information Management System (IMS DB) to an early version of DB/2
  • the transition from mainframe to Unix based systems – specifically with the move from R/2 to R/3, from monolith to client-server
  • the introduction of the in-memory columnar store called HANA

All three of these events are well-known SAP history and already deserve to be remembered as major changes in the timeline.

What did they bring about? Well, initially the move from hierarchical to relational database management systems arguably didn’t bring about anything immediately obvious (except for a wave of horror and unease as we wrestled with the new concepts) – but it was a move without which SAP could not have progressed as hierarchical systems were fixed firmly in the proprietary world of IBM.

The transition from mainframe to Unix based system and the move to R/3 and the new architecture (which I still call “disp+work”) brought about an an agility previously unknown. This architecture still underpins the vast majority of SAP application servers even today. The move to Unix, and initially the proprietary flavours from hardware vendors (AIX, HP-UX, Solaris, and so on) led to the eventual availability of R/3 on Linux, which I’ll come to shortly.

The introduction of HANA needs little explanation … not only did it allow a rethinking of underlying data storage and performance, and collapse the previously dual concepts of transactional and analytical processing into a singularity, but it also brought about a return to monolith, in a way – the database as application server.

Beyond these particular seismic changes, there are smaller but still hugely significant events that I consider major milestones.

Major milestones

Various additions to the general SAP technology set have had huge impacts and effects that are seriously long-term. What makes it perhaps more interesting is that in some cases the significance wasn’t immediately clear, or at least the implications weren’t equally distributed. Over time, however, people came to understand.

There are clearly more major milestones than I could fit into a reasonably sized blog post, so I’ve picked out a handful that are meaningful to me.

Introduction of the ABAP language

I started working on SAP R/2 version 4.1D. There was no concept of ABAP – everything was written in mainframe assembly language; in my case that meant S/370 assembler. Code lived in modules and handled everything from the online transaction processing to the batch processing that was a significant portion of what happened in an R/2 installation.

A year or two into my career we saw a release of R/2 that introduced a report writing language called ABAP – it stood for Allgemeiner Berichts Aufbereitungs Prozessor (English: General Report Preparation Processor) and it started life as a limited set of language elements that you added to your Job Control Language (JCL) to produce classic reports, with headers, subtotals and the like.

ABAP matured as we all know, and is set to be reborn in cloud form, a glue language that binds people and data as we move towards a cloud native thinking powered by a whitelisted set of constructs that allow us to use the power of standard data and metadata definitions and integrate the classic with the new.

R/3 on Linux

One could see Linux as just another Unix flavour, alongside the proprietary flavours, some of which I’ve mentioned earlier. But the porting of R/3 to Linux was more significant than that. It was one of the first major investments that SAP made in the open source world. SAP created a “Linux Lab” and its members contributed improvements to memory management in the Linux kernel so that R/3 would run, and run well.

Moreover, it opened up the possibilities of mere mortals like us running an SAP system on their own hardware, under their control. Mainframes were beyond reach, but not only that – vendor and hardware specific Unix systems were prohibitively expensive. Downloadable installation packages for R/3, to run on your own home-brew kit? Amazing.

The ubiquity of Linux in general is well known, and the fact that one can see Linux as the standard delivery platform for SAP software (including HANA) is just wonderful.

The Internet Communication Manager

This one is my personal favourite. Early R/3 systems communicated predominantly in a proprietary fashion, with Remote Function Calls (RFCs) being the most common method for realtime system interaction. It was possible to make HTTP calls – but only in a roundabout and limited way, via a small utility program that lived on the operating system level, the invocation of which was managed with the same transaction (SM59) that was used to manage RFC destinations.

Then there was the Internet Transaction Server, groundbreaking technology from a team that included Björn Goerke and Thomas Grassl, that was as useful as it was inventive – a combination of Common Gateway Interface (CGI) backends for the web servers du jour with a mechanism that connected to the R/3 backend and fused with the DIAG protocol stream (yes, this was the dynamic combination of wgate and agate, for the SAP tech historians out there). The result was that transactions that were suddenly available … in your web browser! Not only that but it was possible to call remote function modules via HTTP.

But the arrival of the Internet Communication Manager (ICM) – essentially a complete and modular HTTP server*, grafted on to R/3’s dispatcher and communicating via memory pipes – was, in my opinion, an event horizon (and I’ve said so in various talks on the subject in the past, too).

It opened up the SAP world to the open source world in more ways than anything else, and was one of the ingredients that helped turn SAP “inside out” and allowed the embrace of the outside world. It allowed SAP systems to speak HTTP – as client or server – naturally.

What we have today in the form of the REpresentational State Transfer (REST) informed OData protocol, the amazing utility of HTTP as the lingua franca – nay, the communication dialtone – in our everyday architectural constructions and modern developments in the SAP world, are down to the arrival of the ICM and the developer-level Internet Communication Framework (ICF). I was so taken with this that I even created and ran a two-day course on the ICM and the ICF at Manchester’s MadLab a few years back.

*via plugins, the ICM also spoke other protocols such as SMTP

Neo and Cloud Platform

This milestone is almost still too new to think about in terms of being a major one, but I suggest it is exactly that and more. The significance of cloud in SAP’s technology directions is impossible to ignore, and the Neo project, SAP’s first major foray into the cloud space, has been tremendously important.

The SAP Cloud Platform that we think of today grew out of what (and still is) Neo. Yes, of course, there are major new initiatives such as the Cloud Foundry infrastructure and the extensions into Kubernetes, but essentially Neo was what brought us – developers and architects everywhere – to understand what a hybrid and cloud native future could look like in the SAP world.

Amongst other things, Neo provided us with the core infrastructure that we almost take for granted, some of which is essential, and upon which many of the services that we know and love today are built. Neo’s Connectivity service is just one example, so significant and important that we might consider it the sine qua non for the hybrid- and inter-cloud platform age.

Without Neo and the advent of the SAP Cloud Platform, we wouldn’t be looking towards the brave new world of cloud native, nor would we have S/4HANA Cloud.


Of course, this list wouldn’t be complete without including one of the key factors in the success of the new SAP and our ability to consider SAP now being a major player in the enterprise User Experience (UX) arena.

User interface (UI) technologies at SAP have come and gone (some have stayed), and have variously hit or missed the mark, in terms of usability, adaptability and acceptance. A relative newcomer, landing only six years ago, UI5 was, and is, the right technology, the right architecture, and the right UI at the right time. I remember discovering UI5 and writing about it back in 2012 (the article’s date is incorrect, and reflects when I updated it rather than when I first wrote it): SAPUI5 – The Future direction of SAP UI Development? and the significance is still valid and fresh today.

UI5 and the Fiori design language have not only been key to offering a revolutionarily better UX, but they also play an almost unstated and fundamental role in everything that’s currently happening in SAP’s move to S/4 and the cloud. I’d argue that they’ve been an essential enabler for this move, and the combination is still the killer choice, not because it’s the only choice, but for most cases it’s the right choice.

Today’s milestones?

What technologies and advancements today might we come to consider as major milestones? That’s hard to say, but I think there are already some good candidates. I’ll limit it to three for this post:

Core Data Services (CDS): Notable almost by its subtle lack of fanfare and attention, CDS is the quiet engine that is and will continue to power the new programming models for ABAP and cloud native. Perhaps it’s fair to say that we’re only at the thin end of the wedge when it comes to significance and ubiquity – CDS, the rich metadata annotations that it allows, and its supporting cast of technologies and layers will potentially become the technical and mental glue that binds backend and frontend, producer and consumer, operational and analytical.

ABAP in the cloud: I’ve mentioned ABAP in the cloud already; the “third age of ABAP” has the potential to be a stepping stone, not for us architecturally, but for us as a community of developers. A safe and happy landing place that smells and sounds somewhat familiar, albeit being significantly different in some ways, might be the catalyst needed.

Cloud native: this is a concept representing many ideas and technologies, too many to consider individually in this post (although I’ve dwelled on some of them in previous posts in this Monday morning thoughts series). From the new layers in the as-a-service stack, through messaging, event-driven programming, 12-factor app design and container based deployments and service management, this is as far from R/2 as you can get. By the way, did you notice that in this brief list of cloud native concepts that SAP is embracing and building out, that none of them are SAP specific or proprietary?

These are candidates that I’d suggest could become viewed as major milestones in the future. It’s hard to say (and interesting that it’s difficult to recognise truly major milestones while we’re in close proximity to them).

But what I can say is that you, dear reader, will have other candidates in mind. What are they, and why? I’d love to hear what you think – what were major milestones we’ve encountered on our journey already, and what have we to look forward to?

Update 23 May 2018: This blog post is also available via audio, thanks to the awesome initiative from Simon Kemp and Jakob Marius Kjær in the form of Coffee Corner Radio “Pod Bite 1” – see “With every coffee you need a biscuit ?” for more details.


This post was brought to you by Pact Coffee’s Umurage Mbazi, the quiet of a peaceful early morning, and the lovely prospect of spending a day off today with my son Joseph.


Read more posts in this series here: Monday morning thoughts.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Nabheet Madan
      Nabheet Madan

      Thanks DJ Adams  for the blog. I did not know this

      ABAP – it stood for Allgemeiner Berichts Aufbereitungs Prozessor (English: General Report Preparation Processor)

      SAP has been continously changing/improving day by day on it technology stack, right from seeing those Grey GUI tcodes to the beautiful Fiori stuff. I still feel we still have long way to go, this view of mine comes from a very simple experience of mine mentioned below( Being an ABAPer so views are more focussed towards ABAP).

      Few years back i wanted to learn HTML/CSS/Javascript, everything was available, easy to set up, easy to use, super flexible, simple yet so powerful etc. Where as if i want to learn own my own, i need a powerful laptop where i can install my own SAP system. Installation comes with its own pain, errors etc. What i am trying to highlight here is a very simple thing. Why can not someone who want to learn ABAP does not have to go through all of this. It should be as simple as HTML/CSS/Javascript yet so powerful.

      One of the important milestone which i expect SAP to achieve in technical sense is make this ABAP available to public like any other language. That is where we will see great power of adoption of the language. Let anyone and everyone can learn, practice ABAP own his own.

      I believe with out cloud approach we have already opened our doors to people come and learn with us. Hopefully once ABAP is available in cloud people should be able to use it freely(no hidden backend connections) does not matter if it is to learn even.



      Author's profile photo DJ Adams
      DJ Adams
      Blog Post Author

      Hi Nabheet, thanks for sharing your thoughts. I think the desire to open up the ABAP language has been something that many folks have had for a long time. I guess one of the challenges has been that, unlike the examples you mention (HTML, CSS, JavaScript) it is somewhat interwoven into the platform. For example, the ABAP language is fairly impotent without its partner in crime the Data Dictionary (DDIC). And in turn the DDIC is nothing without an implementation of the underlying database abstraction. Add to that the more traditional dynpro processing (DYNP) that was the UI mechanic of the day, and the task handler (TSKH), and you have quite a complex set of runtime artifacts that would be needed to support the language if it were extracted and opened.

      I'm no expert, but the advent of ABAP in the cloud, and what that will imply for the language, brings a couple of immediate thoughts for me on this topic:

      • it's a stripped down version of the language, and as I understand it there will be no concept of dynpro processing, for example - meaning a whole section of the language and runtime becomes unnecessary
      • if it's available in the trial landscape then anyone can come along and learn

      In fact, on that second point, this is already possible with the existing ABAP stack, of course, but then we're back to the discussion on language and infrastructure size.

      I for one am really intrigued and excited by the prospect of the new ABAP in the cloud.

      Author's profile photo Nabheet Madan
      Nabheet Madan

      I for one am really intrigued and excited by the prospect of the new ABAP in the cloud.

      100% excited what it brings to the table:)

      Author's profile photo Robert Shiels
      Robert Shiels

      Nice article, I'm quite glad in a way that I never had to use R/2, sounds ghastly 🙂

      Before Linux, if my memory serves me, hobbyist SAP enthusiasts who had access to the installation DVDs, could get a fairly cheap tower PC and stick their own copy of the system onto a Windows NT box at home.

      This was a great enabler for me at the time - a personal milestone. I still think the simplicity of Windows installations opened SAP up to a lot of people who hadn't been exposed to the Linux/unix world, and didn't want to go there.

      Is SAP on Windows something you approve of?

      Author's profile photo DJ Adams
      DJ Adams
      Blog Post Author

      Hey Robert, thanks for the comments. I think you’re right – Windows NT was also an installation target that was available, I can’t say for sure when it was. And for those less familiar with command line, it was a great option, a great enabler, as you say.

      SAP on Windows? I don’t allow any Windows installations in the house so I can’t comment here.

      ps your Marvin reference didn't go unnoticed, nicely done 🙂