Skip to Content

SAP’s OnDemand Developer Ecosystem (Part 2): The courage to evolve or why SucessFactors’ Cloud DNA isn’t enough for SAP to win the OnDemand Survival of the Fittest

In my last blog about SAP’s OnDemand developer ecosystem, I examined the existing status quo. In this blog, I’d like to consider other aspects of this ecosystem: the SuccessFactors angle, why an OnDemand developer ecosystem is so important and finally a few suggestions how SAP might promote the healthy evolution of this developer ecosystem.

SuccessFactors’ approach to its developer ecosystem: The wrong grail

As I mentioned in the last blog, the recent mobile-related announcements showed a SAP strategy of exploiting partnerships to jump-start the mobile developer ecosystem.  In the OnDemand space, SAP recently acquired SuccessFactors for its “Cloud DNA” .  I was curious if SAP had intended a similar effect in the OnDemand developer ecosystem when they acquired SuccessFactors. 

There is a famous scene in the movie “Indiana Jones and the Last Crusade” where a villain attempts to find the correct grail amongst a room full of different cups.  The villain selects a beautiful cup, drinks from it and dies a horrible death. The ancient knight who has protected the grail for centuries utters the classic line: “He chose poorly.”



When I consider the nascent SAP OnDemand developer ecosystem, I have the same feeling – if the decision to acquire SuccessFactors was made to jumpstart SAP’s OnDemand developer ecosystem, then this choice was incorrect. As the associated PR statements about SuccessFactors demonstrate, other considerations were more important: SuccessFactors’ existing customers rather than its developers or partners.   Take a look at a comparison of the two companies in a recent blog by Sven Denecken:

What SuccessFactors brings:

    • Leadership in Cloud HCM solutions (Talent Management, Workforce Planning & Analytics and more…)
    • Leadership in the Cloud by numbers of users (15M+ subscribed users… already #1 in the cloud by users)
    • 100% Cloud DNA

What SAP brings:

    • +183,000 customers
    • Strong partner ecosystem of e.g. more than 1,700 services partners
    • Business process/ domain expertise across all lines of business and industries
    • Leadership in enterprise applications, mobile, in-memory technology


There is no mention of SuccessFactors bringing a vibrant OnDemand developer ecosystem into the bargain – primarily because there is no broad-based developer ecosystem associated with the SuccessFactors offerings.   There is a partner program at SuccessFactorsit includes some of the biggest names in IT but it includes only 150 names. Compare that to the over 1,700 service partners from SAP. 

Furthermore, there are no publically available APIs, forums, blogs, etc that might provide an interested developer with an initial feeling for the platform.

SuccessFactors’ attitude towards developers represents a typical SaaS-focused approach to developers (also seen in ByDesign) – focus on a few partners rather than a broad-based approach seen in many PaaSs.

I’m not suggesting that the acquisition of SuccessFactors won’t give SAP’s OnDemand strategy a needed shot-in-arm and, after seeing him live in person at the DKOM, that Lars won’t be bring new energy into the program but rather that the creation of a healthy OnDemand developer ecosystem wasn’t a factor in the deal.

If SuccessFactors doesn’t bring this broad OnDemand developer ecosystem to the SAP and SAP doesn’t provide it (as shown in my analysis of SCN in the last blog), then the only response can be that it currently doesn’t exist for SAP’s offerings – despite all that Cloud DNA from SuccessFactors. 

Is an OnDemand developer ecosystem even necessary?

It must be acknowledged that the SAP developer ecosystem in general is currently not one homogenous group but is made up of at least three distinct sub-groups:

  • Large or midsize ISV-partners
  • System integration partners
  • Individual developers or small SAP partners

As the recent mobile announcements show, SAP is also trying to move into other developer groups that are not traditionally associated with SAP. In a recent interview with Jon Reed, SAP corporate officer Sanjay Poonen suggests that there is a desire that these new communities “mingle” with the existing communities.  The idea that a huge developer base is necessary for the mobile space is also taken as a given.  

A healthy developer ecosystem that supports a wide variety of developers, however, is also critical in the OnDemand market.  Although focusing primarily on PaaS rather than SaaS, blogger Brian Sommer stresses the critical importance of developer ecosystems in an excellent set of blogs dealing with ERP PaaSs and developer ecosystems (mandatory reading from SAP’s OnDemand strategy team!):

It is the ease of use with which individuals can use platforms like and iOS from Apple that both transforms the software industry and also the nature of the companies propelling these platform ecosystems. The size of the Apple iOS ecosystem is staggering when one sees the number of applications developed and the number of developers within the community. But more important is the fact that Apple has begun to build a separate marketplace for business applications created through this platform. Understand this, neither Apple, NetSuite, nor are other vendors interested in just building a platform. No, they want to build an ecosystem and they want to do it badly.


The ecosystem is about money. A PaaS ecosystem extends the value opportunity by placing functionally rich, possibly low cost, vertically relevant extensions and new modules within the reach of all ecosystem users. Many of those extensions, modules, etc. come with price tags. The revenue from those solutions represents an income stream to their creators. [SOURCE]

There are various types of OnDemand software ranging from IaaS (AWS, etc) to SaaS (SuccessFactors, etc) to PaaS (Heroku, etc) and the resulting characteristics of the associated developer ecosystem are different as well. 

Regarding SAP’s efforts in this area, the differences between SaaS and PaaS ecosystems are the most relevant.  Since there are no PaaS offerings from SAP currently on the market, the SaaS approach dominates and the focus is on a restricted group of partners who can extend the applications in question.  

An analysis of SAP’s current job openings also reflects this focus. 

The SAP On Demand Ecosystem / Partner unit’s mission is to develop, implement and evolve one consistent partner strategy for SAP Business ByDesign and other SAP OnDemand Solutions. Key objectives are to focus on highly scalable partnerships and partnership models (with low touch engagements) and to follow a holistic approach with concept evaluation and management of strategic partners out of one team. The Business Strategy Manager (f/m) for the SAP OnDemand Ecosystem will identify market and business opportunities and develop Partnering Strategies and Business Models for commercialization.


  • Define and drive the partner strategy and landscape of partner business models for SAP OD Solutions, including monetization of business models and respective business cases
  • Develop and evolve partner portfolio roadmap for SAP OnDemand Solutions, focus on Business ByDesign


Only recently was a single developer evangelist -Matthias Steiner- named for the new Neo platform.

Yet as SAP’s PaaS efforts mature, another approach will be necessary if SAP will be successful in this market. 

As Sommer notes, this is the distinction between power and control:

The power vs. control issue will be a big discussion item in the executive suites of ERP firms. Some vendors will have a tough time transitioning from bring control mavens to facilitators of great ecosystems. These firms believe that:

    • only they can do product development to the ERP product
    • only they can create new functional applications
    • only they can implement the software
    • only they should determine who will be a partner
    • only they can own the customer relationship
    • only they …. (well, you get the point)

Controlling most aspects of an ERP firm may give one a sense of security. But, in the world of PaaS and PaaS ecosystems, it will be a false sense of security. Letting go will need to become a core competency of the modern ERP firm.

Thus, similar as in the mobile space, a broad developer ecosystem is also necessary in the OnDemand space.  It is critical to realize that in the long-term many of the soon-to-be-created mobile applications will run in the cloud and access data in customer OnPremise systems via various cloud-based services.  I found the comments regarding the cloud from Sanjay Poonen during his interview with Reed especially revealing. The central role of the cloud in SAP’s mobile efforts – the ability to “try and buy”, etc – was emphasized but in a vague manner that was largely independent from SAP’s existing and future OnDemand offerings (besides the SAP store).

The current strategic focus on the Sybase SUP (Gateway, Afari, etc) as the application hosting platform for such apps is primarily based on the current absence of a cloud-based solution from SAP that would fulfill this requirement. As JPaaS / Neo emerges from its Beta cocoon, a conflict between the two platforms as the hosting platform of choice for such apps will take place.  

This discussion is based on the assumption that SAP wants to broaden the developer ecosystem for its OnDemand offerings. If on the other hand, the target developer audience for such offerings is developers in existing SAP OnPremise customers, then another strategy is necessary. However, if such a short-sighted strategy is followed, a broad acceptance and dominant market share in the OnDemand space will not occur and other competitors will emerge as the leaders in Enterprise PaaSs. 

As Brian Sommer states:

What is happening now is that market power is shifting to the vendors with the largest ecosystems not to the vendors with the largest installed bases. The distinction is critical and will represent a fundamental shift in buying habits of ERP software purchasers. To ignore the shift in where market power is moving is to do so at one’s peril. [SOURCE]

A recent internal email from SAP reveals that SAP aims for a broad expansion in the Cloud:

German enterprise software maker SAP AG (SAP.XE) aims to double its cloud computing market share this year, and to expand it thirty-fold over the next five years, manager magazin reports, citing an email to employees from board member Vishal Sikka. [SOURCE]

In order to achieve these goals, SAP would be well-advised to follow the example demonstrated in its recent mobile decisions and move to broaden its OnDemand developer ecosystem as well.

How other OnDemand vendors approach their developer ecosystems

Since we were just talking about SAP’s competitors, I wanted to take a quick look at how SAP’s competitors approach their developer ecosystems.



Public Community



API publically Available
























Yes (Example)

I found WorkDay’s approach interesting – its API is public but it has a private partner community – sort of mixing the SaaS and PaaS approaches.

It is very interesting to see who SAP views as its main competitors in this space. You’ll notice that you rarely see attacks on Oracle that focus on Oracle’s cloud offerings – the focus is usually on database-related topics (for example, Hana vs. Exalogic).  Particular SaaS competitors are seen as the greatest threat.    The question is whether this perspective is correct. As blogger Ben Kepes recently suggested in a public LinkedIn discussion, PaaS offerings are gaining in importance:

The other day I had a twitter exchange with someone after stating my view that PaaS will be the future of cloud services. My protagonist countered with a question regarding the rest of the stack – if PaaS becomes pre-eminent, what about the IaaS it’s built upon, and the SaaS that often sits upon it?

My perspective is simple – as infrastructure becomes more and more commoditized, IaaS vendors will look to differentiate, primarily by moving themselves up the stack and offering PaaS-like features.

At the same time, and in an effort to increase flexibility and allow users to harness the copious amounts of data they are creating, SaaS vendors will increasingly move into more PaaS like areas with declarative platforms and tools to analyse application created big-data streams.

If my assertion is correct, the end result is PaaS becoming increasingly important for both ends of the Cloud spectrum

Thus, the real competitors for winning the hearts and minds of developers are other PaaSs. Traditionally, SalesForce would be #1 on this list. I’d expand this list to other platforms that are traditionally not seen as having a “enterprise” focus. If SAP is moving towards the consumer market and the associated market, then it must also change its list of potential competitors – or partners.

Taking Agile Methods to Ecosystem Evolution

Over the last few years, the agile methodology has started making head-way within SAP’s internal development teams – leading to faster release cycles and closer cooperation with the customer.   Björn Görke’s excellent blog series on the evolution of SAP NetWeaver R&D provides insights into how this evolution has taken place.   The customer is central focus of this process:

  • Putting the customer first and having our development processes actually aligned around this has become a primary objective. [SOURCE]
  • Development phases are tact-based with ongoing integration and “working software each tact” is the ambition as our deliverables are being consumed continuously by internal stakeholders or – where possible – validated with customers. [SOURCE]

Björn’s blogs describe how these principles are used internally. I’d like to suggest using them externally as well.  What about applying these same agile principles to the promotion of a healthy OnDemand developer ecosystem? I’ll just take a few of the principles from Björn’s second blog on the topic and demonstrate how they might be used in this task:

  • Be explicit and bold about your goals
    1. There is still much uncertainty and chaos regarding SAP’s OnDemand strategy. Work to assure that developers – not only customers – understand where they fit in.
  • Be realistic and transparent about what you’re doing
    1. Bring all the information from private communities (for example that of ByDesign) and make the information public – preferably on SCN.
    2. Bring all the different sources into one location – a DevCenter for OnDemand offerings.
    3. I know that are different co-innovation OnDemand-related projects with customers (For example, see Jarret Pazahanick’s blog on CareerOnDemand). Consider that the OnDemand developer ecosystem is a new offering – involve the customers in co-innovation – in this case, developers.
    4. Currently, OnDemand offerings (for example, Neo) still have to go through months-long Betas before they go into GA. Follow the philosophy “Done is better than Perfect” and move these products into developers greedy fingers quicker and in shorter release cycles. Provide more resources to support a broader ramp-up.
  • Get top management actively involved
    1. As evidenced by the various other legal problems associated with  developer ecosystems , get upper level management to move these technologies out faster to developers


SAP’s OnDemand developer ecosystem includes more than SAP – it also includes developers as well.  Both sides must collaborate for the relevant ecosystem to develop as desired.  Although may suggest that SAP has put up roadblocks for its success, those developers already involved in the ecosystem have a responsibility as well to assure that it is healthy.  Such individuals must actively work in their own networks to increase interest in SAP’s OnDemand ecosystem – they must see themselves ambassadors / influencers. Furthermore, SAP must actively promote such ambassadors – perhaps even at a personal level. 

There is some indication that SAP is now looking at Cloud-related acquisitions.  SAP would be wiser to use the money to expand its partnerships with existing OnDemand communities (for example, that associated with Cloud Foundry). The key to SAP’s success in the OnDemand market isn’t technology but rather the attitude that SAP has regarding the entire OnDemand developer. I’ll be watching Lars’ moves in this area – can he free himself from his historical partner-driven SaaS approach and embrace a more “open” PaaS attitude. This personal evolution won’t be easy, especially since SAP acquired SuccessFactors for its Cloud DNA which is based primarily on its past success with its niche SaaS offerings.

You must be Logged on to comment or reply to a post.
  • Excellent article and I am always impressed with the detail and research that go into everyone of your blogs.  Truly the gold standard for blogs on SCN.

    One thing that has surprised me is that SCN does not have a SuccessFactors category and curious as to why not as myself, you and Luke Marson has each written multiple blogs on the topic.

    • Thanks – you were the first one who pointed me to the blog series from Brian Sommer – this was important because it confirmed my opinion regarding PaaS.

      Excellent suggestion about the SuccessFactors category – I just retagged the blog with the “successfactors” tag.

  • Hi Richard,

    This is an excellent blog and I think it covers an important topic. If SAP really want their ecosystem to buy into SuccessFactors then they really need to do something that is going to involve them more. A large amount of SAP partners develop their own add-ons, apps, APIs etc and if they can’t do this with SuccessFactors then they will stick to on-premise – and no amount of sales from SAP will force customers to go to on-demand if everybody else is telling them not to.

    Best regards,


    • Luke,

      Excellent point. I was taking a more general approach to developers but existing SAP HR partners may be facing a similar  dilemma – no public information about SuccessFactors integration and no real support to help them make a potential move to the OnDemand world.


  • Hi Dick,

    wow, you sure are on fire these days! Another deep and well-written blog – as usual.

    You mention a lot of valid points and when reading your blog it’s clear that you got to the conclusion that things are not looking good in the area of OnDemand/Cloud and the developer community.

    Just by looking at the team I’ll soon join I can rightfully say that there has been a Cloud DNA inside SAP a while back. I can also say that joining forced with our new colleagues from SuccessFactors have been very positive indeed.

    Concerning the importance of a healthy and growing developer ecosystem you know my stance – matter of fact it was the essence of my presentation at TechEd last year when I talked about Community-driven development on SAP NetWeaver Neo.

    I believe that Neo will be attractive to developers for many reasons and regardless of the size of their employer or coding shop. That’s the driving idea behind it all: lowering the entry barrier, freedom of choice and ease of use.

    And that’s a base mix that should flow well with developers of all sizes and in all camps. And no, we are not ‘that’ short-sighted to only look at the installed based. 😉

    I think there’s a very simple reason why there’s not yet a thriving public(!) community is that we opted for a closed beta. Now does that make sense for an open-platform? You decide… we had our reasons, yet whatever I’d say you clearly stated your opinion on this so… I can safely say that people understand that open platform implies open communication so give it some time and we may get you happy once the BETA is past us.

    Regarding the two spaces mobile and OnDemand cannibalizing each other… I don’t see that. And even if there would be a friendly rivalry to win developers’ heart would that have to be a bad thing? I mean, for SAP it would work either way as long as they use either one (why not both?)

    In fact, one of the things I find promising in this regard is that there’s a certain overlap of skills in those two camps: HTML5 is a prominent choice for the presentation layer. JSON and REST seems to be a a commonly required skill. For both kind of apps, especially when coding against backends you’d also need some knowledge about the involved business processes and how-to access that data. Gateway may cater to both camps… plus there are more options to choose from

    So at the end of the day, for me it sounds like it should be easier than ever to build great cloud apps with multi-channel access. RESTify your service layer and you can use whatever UI technology you’d like.

    At SAP, we have always aimed to provide choices and alternatives and Neo is just the next evolution of that paradigm in my POV.

    …and as you mentioned me personally in your blog. Well, yes… we only got one Evangelist on the team, well, let me rephrase that… there’s only one person with that primary role on the team. You know them, right?

    One last remark about your suggestions – I think it’s great that you provide constructive feedback and share your expectations. I have been chiming the same chord for a while now, and well – they gave me the job. So at least for me – I take it as a positive sign that hopefully we’ll soon see some of these things happening.

    Best regards,


    PS: As a big Movie fan I cannot help but feeling the urge to counter your intro quote with refering you back to our name “Neo – The Chosen One!” 😉

    • Regarding the two spaces mobile and OnDemand cannibalizing each other… I don’t see that. And even if there would be a friendly rivalry to win developers’ heart would that have to be a bad thing? I mean, for SAP it would work either way as long as they use either one (why not both?)


      This may be true but then the mobile-related use cases for each platform must be better articulated – otherwise, people are going to be very confused.

  • @dick – I am slightly confused by your table. Can you say how you are defining each element. For example, I know that Oracle has blogs and forums but then there are also indirect non-Oracle sponsored blog groupings.

    Similarly, I know Workday has private forums for ideation. At the Workday 16 analyst call they made mention of 57 customer driven enhancements making it into the latest release. I realise that’s not the same thing but then WD is focused on building out systems of record. I’m not sure they’re ready to move into PaaS in the way you describe so I’m not sure their inclusion is relevant in this context?

    • Regarding the table about the efforts from other vendors, I basically got on their sites and checked if such collaborative offers were available for developers. I have to admit that my efforts weren’t as extensive as they might have been but I just wanted to provide a quick comparison to show that in some ways the situation at SAP might not be unique.

      I’m not suggesting that vendors shouldn’t have private areas where they collaborate with partners or customers but I’d like to suggest that these areas should be kept to a minimum if possible. 

  • @dick – On a separate point, at the WD16 launch, Stan Swete, CTO said that they see mobile and cloud converging so that for instance they are of the belief it is worth re-engineering the Flash based browser experience to HTML5. Aneel Bhusri reinforces that:

    Lastly and importantly, our foray into HTML5 for mobile devices paves the way for Workday to adopt HTML5 as our desktop browser platform. At this time, we feel that HTML5 is not quite ready to fully replace Flash for desktop browsers as there are still gaps in functionality in areas such as complex graphing and org charts, as well as its lack of wide-reaching browser support—key requirements for enterprise apps. But those gaps are closing quickly, and we expect to transition from Flash to HTML5 as soon as it’s ready for the desktop. I don’t expect it will be too much longer before I pen a similar note about that topic.

    I see that as a potential inflection point. Right now, there seems to be some acceptance inside SAP that mobile/cloud (on-demand) are closely related but I am not clear whether they are on separate trajectories.

    Once again it opens up a whole set of inter related debates and problems.

    • Right now, there seems to be some acceptance inside SAP that mobile/cloud (on-demand) are closely related but I am not clear whether they are on separate trajectories.

      Once again it opens up a whole set of inter related debates and problems.


      I also see that there is some acceptance of the close link between mobile & cloud. I get the feeling that SAP’s mobile strategy is solidifying (although details about use cases to help customers / developers make the associated platform decisions are still missing). Regarding the Cloud, things are more chaotic. Although the SuccessFactors acquisition may have been seen as an appropriate response to the uncertainties of customers, developers and partners in this area, the fact that the dust still hasn’t settled shows that things are still in flux.