It has been awfully quiet around the River platform. After its initial announcement in 2010, private mentor program, beta programs, trials and innojams, the service apparently didn’t catch enough steam for a successful birth. Instead, SAP management has decided to discontinue SAP River platform development, with the exception of SAP Carbon Impact. To me, this came as quite an unexpected move, as most reviews and blogs on SAP River showed a very positive verdict.
Reasons for shutting down River
One can only guess about the reasons for the shutdown:
- River is a RAD tool based on data modeling. Is a modeling tool perhaps not the preferred development environment of cloud developers? In a private SAP Mentors meeting Hasso once pointed out that modeling does not mean much for developers.
- Did it still take too much effort to build applications? Although the data-model could be setup very quickly, adding business logic, applying a custom skin to an application or understanding River’s REST API had a huge learning curve to my experience. And if relatively complex application like SAP’s Carbon Impact needs to be built, it would probably still require a little army of developers.
- Has SAP not been clear enough in its positioning of River and what it could be used for?
- Although it’s all about “Run Better” at the moment, many haven’t forgotten about the “Run Anywhere” yet. This doesn’t only apply to the plethora of devices modern software is supposed to run on, but to my opinion this should also apply to cloud vs on-premise. Is it because building an on-premise version of SAP River was too challenging and did customers/partners find the risks of running on a cloud-based platform only too high?
- Is it expected that the RAD tools built in SAP River be surpassed by Eclipse based RAD-like tooling? SAP has proven to be good at building Eclipse based modeling tools, such as the toolset built for Web Dynpro, the Composite Application Framework (CAF), but also the initial code of the JPA Diagram Editor (which was awarded Eclipse Best Developer Tool award for 2011). And I can’t wait for the expected goodness around Neo, ABAP in Eclipse and SAPUI5.
I tend to believe that the real reason is probably a mix of some of the points mentioned, although I strongly feel that the latter point is most crucial. SAP is betting on Netweaver Cloud (Neo) and together with a little boost in eclipse based developer productivity tools, developer productivity could be on par with SAP River’s modeling tools. And if you’re betting heavily on a platform, it makes sense to shift many of your resources there.
Several years of development weren’t in vain. I am very sure that internally, many new ideas have sparked of from the River project:
- The River project must have gained SAP a lot of insight in the technology that it currently applies. River was their first PAAS and to some extent, you could even call it the predecessor of SAP Netweaver Cloud. SAP River was also one of the first adopters of SAPUI5, and applying it to a prestigious platform as River would probably provide the SAPUI5 team with a lot of feedback. SAP River was also on of the first platforms that showed a REST interface, allowing for a more loosely coupled user interface layer.
- RDL (River Definition Language) started off as a new language that was targeted to be embedded in River. It has eventually been embedded within the HANA server as the application language, to build native HANA applications.
It has taken approximately five years to introduce HANA as a product (2010) after SAP’s initial acquisition of Transact In Memory (2005). It wouldn’t surprise me if a few years down the road, we would see a new announcement from SAP, starting with “Remember River of back-then?…”