Will SAP River lead to an ocean of productivity ?
Over the past couple of weeks SAP have been quietly showcasing a new programming model called River Description Language (RDL) or just River for short. Some people have described it as Vishal Sikka’s vanity project, as River has been in the works for quite a while now (something called River has been with us for at least 3 years) and Vishal does not want to give up on the idea. I personally don’t see this as a vanity project, but as a sign of belief in the idea….so what is the big idea.
The concept of River is linked to the idea of ‘Timeless Software” – and if it can deliver on its promises it could deliver just that – a language to that you can use to describe the business logic of your Business Software, separate from implementation.
River and Java
For those developers out there, you might be crying out “but isn’t that what Java does for us already ?”, we write the business logic in Java, compile it and then run it on (almost) any Java Virtual machine (JVM).
Where River is different is that it is trying to separate the intent of the program from the complier, in the River paradigm each platform will (might) have its own compiler that will take the RDL which holds the business logic intent and compile this to the most appropriate artefacts that that platform has to carry out the task that has been requested.
So for example if the target platform supports column store databases then these could be used by the complier, for those that did not offer this feature then the compiler could use a row store. Perhaps most importantly it is the complier that makes these decisions not the developer.
So imagine what would be possible if R/3 had been defined in RDL and then deployed to an ABAP server via an RDL complier (note at the time of writing no such compiler exists). It would all now be OO-ABAP and take advantage of the In-Memory capabilities – just by re-compiling !
Where are we now ?
The first version of River only has one target platform – you guessed it – HANA. It is possible via the HANA Studio to create an RDL model and then compile this to HANA artefacts – The developer does not choose if the logic is created as Java Script, SQL Script etc, they just define the intent and the compiler decides what to do.
So is it a good idea ?
As a general concept, I think that River is a really good idea. I also think that using HANA as the first platform is a good idea for two reasons. The first is that not so many developers really know how to get the best out of HANA and the second is that the capabilities of the HANA platform are evolving quickly – so best practice today will not be best practice in 6 months time. RDL will take care of both of these potential issues by removing implementation decisions from the developer and a quick recompile will make sure your application is using the best HANA features.
Personally, I would like to see other target platforms at least committed to, as without this I can see that we run the risk of HANA specific “extensions” finding their way into the RDL specification – at which point it becomes a HANA Description Language. Only time and adoption will tell.
Nice summary Owen. I am very interested in RDL and looking forward to trying to build some real solutions with it in the near future. Many people - some who's opinions I value - are sceptical about River but from what I have seen in the past couple of months it looks quite promising to me.
I had a similar opinion until we got to have a look at it - it should make developing HANA apps easier. Even better if we see compilers for other target platforms and perhaps open source the definition 🙂
River and RDL is something new for me, thank you for bringing it up in the blogs section and giving a very nice overview.
Great summary Owen !!!
In the medium term, we definitely want to be able to compile SAP River to other runtime platforms as well.
I definitely think there is room for the RDL. It sounds like a functional programming language(FPL) (like SCALA or Closure). Now as soon as you say "functional programming language" some business types immediately jump up and down shouting that we can finally get rid of developers, and that the business analyst can write the code.
It's still a programming language (aimed at developers) but it does remove a lot of the decision making (and complexity) to the compiler, leaving the software engineer to focus on the requested functionality.
I believe that such FPL's are a good fit for Rapid Application Development and recompiling when the underlying core changes.
Being a hard-core techie though, I'll probably use RDL to quickly model my application, and then hack away at the generated code to make it mine 🙂
Thanks for summary.
For a slightly deeper dive, have a look here.