Skip to Content

Guerrilla Tactics for SAP’s OnDemand ‘Go to Market’ Strategy

At the recent SAP Influencer Summit in December, SAP detailed its OnDemand Strategy.  

Of all the comments that emerged in response to this event, one in particular made me aware of the difficulties of this endeavor.  

 

SAP is years behind Salesforce.com in delivering an on-demand platform and supporting infrastructure. More than 185,000 apps have been built on the CRM vendor’s Force.com platform, and more than 700,000 instances of those apps have been installed from Salesforce.com’s online AppExchange. [SOURCE]

 

When I read this quote, I took a deep breath and sat back in my chair. I was suddenly aware that an excellent OnDemand strategy and awesome technology isn’t enough to be successful in this market.  Without a thriving development community (such as that present in the SalesForce community) the best “Go To Market” Strategy – regardless of whether the product is OnPremise or OnDemand – is doomed to failure. 

Note: In a recent podcast with Jon Reed and John Appleby, we discussed this issue and John suggested that many of these apps won’t be necessary in the SAP environment, because the functionality is already present (for example in BusinessByDesign). In my opinion, this is missing the point. The quote for me is important for its focus not on functionality but on momentum.

I’m not the only one who is aware of this shortcoming. In a Twitter conversation about River, RedMonk analyst James Governor had this response

 

Of course, you could respond and say that SAP already has a powerhouse developer community (SCN) . This community is, however, largely focused on the OnPremise product line. The OnDemand-related efforts in this environment are nascent and have yet to create any real momentum or tangible excitement in the SAP developer community.  

As a SAP Community Podcast: Talking SAP On-Demand with SAP’s John Wookey from Jon Reed with John Wookey and Michele Rodman-Bilafer Siva Darivemula reveals, SAP is working on making such OnDemand-focused communities available.

 

18:25 Jon to Siva: How can listeners get involved with the on-demand conversation on the SAP Community Network? SivaWe are launching a community that should be available to the broader public in a few months or so, and we want the community to share their opinions. We want to know if what we’re doing is on the mark and what they want to learn more about. From blogs or discussions, we want to hear from the community, we want these resources to be valuable to the community. 

 

Such efforts are laudable but I’d like to propose a more radical approach. 

Guerrilla Tactics

Lately, I’ve been exploring SAP River and have been impressed by the possibilities it represents.  The following suggestions will be focused on River but I’ll also propose some suggestions for other SAP OnDemand products.

River: Don’t deny the past. Don’t accept the past. Exploit the past

On February 19, 2009, SAP acquired Coghead – a web-based enterprise software environment. After the acquisition, Coghead disappeared. If you try and access http://www.coghead.com/ today – you will get a DNS error stating that this address doesn’t exist.

Coghead is the basis for River.  This origin is apparent if you compare the River UI and the old Coghead development UI and the various Coghead relics (for example, “com.versai:Bacon” in the River REST API).

Of course, SAP has continued to develop the Coghead code base and has added various improvements.

Once you acknowledge this debt to Coghead, the question becomes: How can you exploit this fact to jumpstart SAP River’s momentum in the developer community.

I’ve been researching Coghead via various means (including the WayBackMachine which gave me access to the old Coghead website) the last a few weeks and have a few radical suggestions based on this research.  

Suggestion 1: Exploit Coghead’s Developer base 

At its heyday, Coghead had over 17,000 developers using the platform to develop applications.  I’m hoping that SAP still has a list of these developers.  I’d suggest contacting each of these developers and informing them about River.  Maybe, something like this: 

Dear Coghead Developer,

We’ve wanted to inform you that after our acquisition of Coghead – we’ve been busy and have used this technology as the basis for our new OnDemand development environment “River”. This new platform is of critical importance to our new OnDemand strategy.

We’d like to invite you to join us in this new exciting endeavor.  We’d welcome your participation in our new River Community with its forums, wiki, etc.

Here is an invitation to our preview environment…

Sincerely,
SAP River Team

Of course, some of the developers’ email addresses may no longer be valid. Other developers might still be angry that SAP pulled Coghead offline.  Most would have to refresh their Coghead developer skills – dig out their old Coghead code snippets. However, imagine the impact if  1000 Coghead developers joined the new River community on SCN which is currently slowly getting started. Questions would be answered faster and a new excitement would permeate the community. 

I’d also contact those Coghead developers who created applications and ask them to think about porting their applications to the new environment.

Of course, the question is whether those old Coghead applications fit into the current light-weight focus for River but a number of these applications might fit this new paradigm.  These applications could provide the foundation for SAP’s upcoming push in the OnDemand marketplace.   

Suggestion 2:  Put the old Coghead applications into CodeX

At its heyday, there were a wide variety of Coghead applications that were available. Dig up these old applications – especially the ones that were created by the Coghead team-  and drop them into the existing River Samples Codex project.  For some of these applications that were built on an older version of Coghead, a port may be necessary. Place the code to be ported in the CodeX project and let the community do this.

Developers need code examples. These old Coghead applications contain an amazing amount of code / ideas. Let’s reuse this stuff.

Don’t store these applications as documents in the CodeX project. Store the source code in SVN; thus, it is easily accessible and developers might be more willing to improve them.

Suggestion 3: Resurrect the old Coghead documentation

There is now an “River” OnDemand [remove]  and SCN River wiki . However, as I discovered when working on my Apache ESME – SAP River Integration, the River documentation – although growing on a daily basis – still isn’t enough. Some might say I’m impatient but developers need examples / hints / tips to work efficiently.

As I stated above, there was a vibrant Coghead developer community.  Coghead also had a platform to support this community – there were forums, tips, tutorials FAQs, etc.

Let’s reuse this material. James Governor also agrees with me.

 

I found an amazing amount of material doing my archival research:

 

 [SOURCE]

Of course, some of this material might be outdated. Ideally, the SAP River team would place this material in the wiki and let the community dig through it, restructure it and check to make sure it is still valid.

If SAP doesn’t give easy access to this material, interested developers will find it anyway. As the quote from movie Jurassic Park suggests “If there is one thing the history of evolution has taught us it’s that life will not be contained. Life breaks free, expands to new territory, and crashes through barriers, painfully, maybe even dangerously. ” , this old material is available and will be used – in spite of the difficulty involved to dig it out of the old archives.  Rather than fighting such guerilla tactics, SAP should support them in order to create a flourishing developer community.

Suggestion 4:  Open-source the Carbon Impact application

SAP’s Carbon Impact is a new OnDemand application based on River. It was selected as a test of the capabilities of the River platform, because it was a complicated application that involved many of the more advanced features of the new environment.

Place the entire codebase of this application into CodeX.

Let other developers see how SAP creates a complicated River application. It would be excellent chance to provide examples / coding standards for the growing River community

Suggestion 5:  Place all the River videos on YouTube

Currently, the majority of River instructional videos are either restricted to developers who have been lucky enough to get access to the preview environment or have joined the CodeX River Sample applications project.

Create a SAPRiver YouTube channel and make all these videos publically available. Continue to create new videos and solicit videos from other River developers / users.

I’d suggest looking at the excellent StreamWork SAP StreamWork Product Tutorials – SAP Community Network for ideas. 

Suggestion 6:  Move code from the CodeX project to the SCN Wiki

Currently, there are some very useful code snippets in the CodeX project (for example, “Push River Data to BI OnDemand ) and thus only available to CodeX members.

Move this code to the wiki where the public can see it, use it and improve it. 

Just use CodeX for applications not for documentation or code snippets.

Suggestion 7:  Get Coglets working again

Coglets were tiny code snippets that were developed to embed Coghead content in a variety of other applications. They were way ahead of their time and there a variety of Coglets that were available. Having this code available would allow River developers to embed their data in a variety of platforms.

Suggestion 8:  Combine the internal / public SAP River collaboration groups / links

In a recent presentation stored in SAPRiver CodeX Project, the SAP River team lists internal and external collaboration sites.

I’d suggest combining these sites as much as possible. Cooperation between internals and external River developers should be promoted as much as possible.

Suggestion 9:  Create a feedback page

StreamWork’s Feedback functionality should be copied in River.

Streamwork

Suggestion 1:  Place StreamWork templates in Codex

Currently, there is no single location for users to look for StreamWork templates.  The StreamWork team should establish a CodeX project where users could contribute their own templates.  There was a recent SAP StreamWork and the healthcare challenge about Streamwork and healthcare entitled “SAP StreamWork and the healthcare challenge”. Such blogs should include a reference to a Healthcare StreamWork template.

Suggestion 2:  Promote more code examples. Create a CodeX project

Although the StreamWork API  is well-documented, you rarely see any examples of working code. Yes, there are a few code samples available from the StreamWork team but nothing from developers from the community.   There are now a few CodeX projects concerning OAuth usage (critical for integrating with StreamWork) but no real projects based on this code. I’ve never seen any demo projects that are based on the Method API.

StreamWork is a full-blown SAP product that is constantly getting new features; I have to yet to see any passionate developers who are developing code for it.

BusinessByDesign

Suggestion 1:  Don’t create a separate developer community for partners

On occasion, I’ve heard some indication that there should be some separate community for ByD developers. This would be a mistake. Exploit the passion and experience of the existing SCN community.

Suggestion 2:  Find a BusinessByDesign SAPMentor

This suggestion may be premature. I know that the ByD SDK hasn’t been released yet.

Still, I’d like to suggest that there be a SAPMentor who is a BusinessByDesign expert.  The synergy would be amazing and the inclusion with this group would help promote this new development environment.

All three OnDemand Products

Suggestion 1:  On-Demand Evangelists who are active

Each OnDemand environment needs to find evangelists who are active in the developer community. I’d suggest looking at Marilyn Pratt and her experience in the BPX community as the example to emulate.  Marilyn knows everyone in her community and promotes collaboration amongst members. Such skills are important to nurture the OnDemand developer communities as they evolve. 

Conclusion

Some might suggest that I’m being presumptuous and encroaching in the responsibilities of SAP’s product managers who are accountable for GTM strategies. As the quote in my introduction suggests, developer momentum is critical in such endeavors. Volume is the foundation for success in the OnDemand marketplace and for SAP to catch up with other vendors a vibrant developer community is necessary.  My suggestions above focus on non-traditional means to capture the attention of such developers.

The SAP developer community and SAP OnDemand product managers both have the same desire:  let’s make these platforms a success. 

In the end, such collaboration benefits customers as well – they get more innovative solutions faster and more efficiently.

3 Comments
You must be Logged on to comment or reply to a post.
  • SAP really is a little behind SF on this how have just acquired Heroku but SAP have come from behind in CRM and BI before.
    As you say though… why start from scratch?
    Nigel
    • “Why start from scratch” is an excellent description of the strategy that SAP should follow. Regarding River, the old Coghead foundation (with all its potential) represents a good foundation for the future – why waste it.

      D.

  • Hi Dick,
    I agree completely with you that it makes sense to re-activate as many members of the previously thriving Coghead community as possible and use them as the core or starting point of the River community.
    As to whether or not it would be wise to locate a ByD community in SCN – I imagine that a ByD developer/customizer might easily feel overwhelmed on SCN, and finding relevant content might be as difficult as finding the needle in the haystack for them. So I tend to think that, while SCN would profit hugely from the presence of ByD experts, for them it might be better to have an environment of their own in the growth phase which could later be merged with SCN.
    I believe that one of the distinctions between ByD and River is that River appeals (also) to Business Suite customers, so the River community will have a significant overlap with the existing SCN crowd – making it a reasonable choice to locate it on SCN as well. ByD, however, is going to have a distinct set of customers: Whoever is using the Business Suite will not by using ByD for a while and vice versa. This is also true for content: None of the Suite and NetWeaver related content in SCN is going to be relevant for ByD customers (correct me if I’m wrong). Given the huge SCN community and the – at first – tiny ByD community, I understand the pledge to give ByD customers their gated community where they don’t feel overwhelmed by Suite and NetWeaver content, but I won’t let that excuse go for River developers. 😉
    Cheers,
    Thorsten