SAP “Project River” – how does it compare to xyz?

At TechEd 2010, SAP started spreading the word about its new on-demand platform codenamed “Project River” (just “River” from now on) – we even let the community use River at Innovation Weekends in Berlin and Las Vegas and Innovative Community Day in Bangalore. Since then, I am quite happy to see a lively discussion about this not-yet-released platform on Twitter (#sapriver), the “River” OnDemand [remove], and even in a River Wiki started by SAP Mentor Richard Hirsch.

But as River is neither released or available as a public beta, there’s also some uncertainty how River relates to other SAP on-demand offerings (namely Business ByDesign and StreamWork) as well as other on-demand platforms out in the market. As I have worked with some of those technologies and played with all of them, let me share my thoughts on how a developer could decide among so many choices…

River AND ByDesign

It has been argued why SAP would push two PaaS (Platform as a Service) offerings into the market. Wouldn’t one be enough? Maybe. But I want to state that River and ByDesign tackle entirely different market segments and choosing between River and ByD should be fairly easy when you know what you want to build.

Core and Edge

At last year’s Sapphire, our CTO and member of the executive board, Vishal Sikka introduced the distinction between “core apps” and “edge apps”. Later at TechEd both in his keynote and in this very insightful interview with Jon Reed (aka JonERP), Vishal explained what is meant by these terms: core applications are the ones that run your business. Your most important concern as a CIO is reliability and stability of the core. The edge is where you can innovate without putting your core at risk. And ByDesign is meant for the core, River for the edge.

OK, that may sound convincing, but still fairly abstract. Aren’t there precise definitions of “core apps” and “edge apps”, or a least some criteria catalog where I could tick some boxes and get “90% core” as result?
Unfortunately not. And there’s also migration between the two – some innovative new spaces might start as edge and over time become core – CRM started on the edge some 15 years ago, now most CIO’s might call it core. And I suspect that the first edge application SAP ships on River, SAP Carbon Impact, will be a core application for a lot of industries in only a few years from now. Migration can also happen from the core to the edge, with functionality that use to be critical for a company loosing importance over time. 

A closer look at River and ByDesign

River is essentially a development platform somewhere in the web (or “the cloud”). Using nothing else but your browser, it lets you model data structures, user interfaces and business logic contained in functions (or “actions” in River terminology). Once you are done describing the screens of your application, you can already start to enter data.
When you sign up for a River account, it is pretty much empty. To fill it with life, you either purchase applications or components from an app store (which will hopefully exist in the future), or you build your application from scratch. River offers capabilities for connecting to SAP on-premise systems as well as to other cloud-based services. But you will have to build your own application content, just like an SAP development team built SAP Carbon Impact and its connectors to SAP ERP, EnergyStar and others.

SAP Business ByDesign, on the other hand, is not only a development platform. It is also a full blown suite of business applications that can be used to run the entire business of a mid-sized company. Financial Accounting, CRM, SRM, HR, Payroll, Production Planning & Execution – you name it, ByDesign has it.

But there’s even more: ByDesign is a programmable business suite, and all the logic contained in the platform follows the same patterns, both regarding the exposed interfaces and the internal implementation. Members of the ByDesign community speak of “Business Objects” (something like a Customer, a PurchaseOrder, an Invoice, and so forth) which are made up of “Business Object Nodes” (essentially flat data structures like a Customer‘s PostalAddress) that are connected via Associations (both inside one Business Object, e.g. a Customer can have multiple PostalAddresses and between Business Objects, e.g. an Invoice points to the Customer that has to pay the Invoice). As a developer on ByDesign, you will find an environment that lets you consume and extend the existing Business Object library. Your main challenge as a ByDesign developer will be the decision when to consume (because the functionality you want has already be implemented) and when and where to extend. We are talking about hundreds of Business Objects consisting of thousands of Business Object Nodes and in total around 150,000 fields – so there’s a lot to browse and learn…

So here is my personal conclusion:

• Use River for small greenfield projects. If you need an environment to quickly build a simple application, maybe with some connectivity to existing business applications (including ByDesign via SAP Data Protocol and OpenSocial), and if you don’t want to set up your own servers and infrastructure to operate and maintain this application, have a look at River. You can build simple, yet reasonable, applications within weeks. At Innovation Weekend, first-time users of River have built applications within hours. Hours! Including iPad UIs, Integration with BI OnDemand, StreamWork and so forth…
• If you are looking for an on-demand Business Suite that can be adapted to your needs, check out ByDesign. If you have a huge custom development project and major parts of that project involves best-practices business processes, whereas other parts need to be custom-built, ByDesign may also be worth a closer look. Yes, there’s a steeper learning curve than with River, mainly due to the huge existing Business Object library. But for a bigger project, it can save you a lot of time when you don’t have to implement an entire business process, but instead just pull it in…

River vs. Heroku

It was probably just a coincidence that while SAP held our 2010 Influencer Summit, just a few miles away from Santa Clara, Salesforce.com announced their acquisition of PaaS-provider Heroku. I myself stumbled across this blog by Alex Williams which got tweeted and re-tweeted, and as I have always been a happy Heroku user (those of you who have read about my work on Blue Ruby may have guessed that already), let me comment on this analogy:

In a certain sense, comparing River to Heroku makes a lot of sense:

• Both give you a place “in the cloud” to deploy and run your applications. Security, availability, scalability (both run on Amazon EC2 as of now), backups and so forth is all taken care of.
• Both make it very easy to get started:
  Heroku by leveraging Ruby on Rails, the web application framework that has pushed the limits in terms of developer productivity, and by offering all the libraries that millions of Ruby developers are used to work with anyway.
  River, by raising the level of abstraction even further and letting you graphically model a working skeleton of your application within minutes

If you look a little closer and and compare the ways to program the platform, you’ll find fundamental differences:

• Heroku is for Ruby developers. If you are a Ruby developer, you must love it. If you are an ABAP developer, you may have never heard of it. If you are not a developer at all, you’ll go and find someone familiar with Ruby to build an application for you
  River raises the level of abstraction. You “program” in a graphical environment where you define database table, RESTful remote APIs and query engines by dropping fields on a canvas. In a way it enables business experts to build the first working versions of an application before it is polished by a developer. For the developer, River offers server-side Javascript and Flex and/or HTML/CSS/Javascript for user interfaces.
• Heroku gives the Ruby developer choices. Rails or Sinatra, mySQL, couchDB or PostgresQL, extjs or jquery, it’s all up to you. Exactly what Ruby developers want and I feel very productive writing my Sinatra applications in TextMate and deploying to Heroku. However, although the defaults make a lot of sense, you get easily overwhelmed by the amount of choices you have. And in bigger projects, different choices made by different teams or individuals (more often than not out of personal preferences rather than necessity) can lead to inconsistent behavior and difficult lifecycle management
  River – remember, raising the level of abstraction – has made a lot of the choices for you. You don’t program against a database abstraction API, you just define what you want to persist. River will take care of it. In the last two years we have actually replaced the database technology three times (with the next change already happening), without any impact to the applications.
  On the downside, that means that developer’s opportunities to fine-tune the system are limited. For the real developers, who feel more productive with a programming language than with a modeling environment, the River team added support for server-side Javascript that can be used to express the “business logic”. And there’s more to come…
• Heroku allows you to develop locally, in your preferred IDE or editor. As a Ruby developer, you can stay in your familiar environment. Deployment to Heroku is done via GIT, which has become the de-facto standard for Ruby projects.
  River, however, comes with built-in authoring tools. You do not only run your applications on the cloud, you even build them on the cloud. Lifecycle management, application versioning and sharing – it’s all built into River. And again, for the developers who prefer a real IDE, the team has added experimental Eclipse support, so you can build your applications in Eclipse and remote-deploy these applications into your River account. And yet again, there’s more to come…

River vs. Google AppEngine

* Re-read the paragraph on River vs. Heroku.

replace all occurrences of ‘Heroku’ with ‘AppEngine’.
replace all occurrences of ‘Ruby’ with ‘Java or Python’.

* that will leave some false statements (e.g. about deployment via GIT),
* but should be good enough

River vs. Visual Composer & Composition Environment

River, emphasizing graphical modeling of user interfaces and business logic, has of course been compared to Visual Composer. However, I don’t think this is a fair comparison, because:

• Visual Composer is being used to model user interfaces on top of existing business logic that is exposed via web services, RFC, …
  River, on the other hand, lets you describe your entire application. User interface, business logic, persistency – all within one coherent development environment. You can connect to external services, but that’s not the main paradigm.
• Applications built in Visual Composer – and also SAP Composition Environment (CE) – basically run on your own infrastructure. Yes, you can take your CE and put it on Amazon – but you will be responsible for operating the applications you build and for maintaining the platform the apps run on. For a certain type of applications, this may be exactly what you want – the whole composite application movement was about re-combining existing applications that already run, so we certainly want the composition close to the base applications. 
  River, however, gives you a complete environment to build, manage and run your application in the cloud. If your application is not just a re-combination of existing services, this may be the better choice.

River AND StreamWork

In an ideal world, these two technologies should be one, at least in my opinion. However, a company as big as SAP can never be the ideal world. So SAP ended up building two on-demand platforms that have certain overlap, do not tackle the exact same use cases, but are most powerful when combined. The good news is, we are consolidating, and we are integrating. We can feed River data into StreamWork activities as OpenSocial Gadgets and we can create new records in River from these Gadgets already now. We can access the StreamWork REST API from River to read, create and update StreamWork Activities already now. In the labs, we have seen River and StreamWork running side-by-side on the same Netweaver Java server with a shared user management (yes, this means single sign on!). And if I now even thought about the potential of both implementing SAP Data Protocol (the Atom Publishing Protocol dialect behind “Project Gateway”) in future, I would start to day dream – so I better hold myself back…

River vs. Coghead

The specified item was not found. and others have found it, and there’s no reason to deny: the roots of River are in technology built by Coghead – SAP acquired their IP in early 2009. Since then the platform has undergone major architectural changes, so the old Coghead applications will not be compatible any more. However, Coghead developers will still feel familiar with the environment and would probably also be able to migrate their existing apps with a little effort.

As the development team is rounding of the platform, the go-to-market is currently being defined. As impressive as the Coghead was back then, in the end they have not been able to survive in the shark tank PaaS market. So SAP may or may not take a different approach, this is beyond my knowledge and competence. All I can do, is ask you for a little patience – we are all desperately waiting for the announcement of a public beta program or something comparable. BTW: you will read that announcement here on SDN first, not on any non-SAP blogs 😉