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...
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.
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.
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:
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:
If you look a little closer and and compare the ways to program the platform, you'll find fundamental differences:
* 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, 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:
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...
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 😉
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
36 | |
25 | |
16 | |
13 | |
7 | |
7 | |
6 | |
6 | |
6 | |
6 |