Skip to Content

One of the most important characteristics of the emergence of cloud applications is the necessity of having a vibrant developer ecosystem that complements the core functionality provided by the application itself.  This trend applies to both consumer (ie Twitter) and enterprise-focused (ie Workday) applications.

What happens, however, when the developer community starts to create applications which compete with products / features offered by the SaaS itself? How does the company respond? Does it view the competition as healthy or as a threat? 

Note: This blog focuses on internal competition that emerges from the developer ecosystem associated with a particular cloud application rather than external competition which comes from the marketplace (for example, NetSuite vs Business ByDesign).

Note:  Competition might also take the form of the extension of a particular feature rather than copying the entire application.

In this blog, I’d like to examine how SAP might respond to such an occurrence.  First, I’d like to examine two recent examples that demonstrate a more aggressive response to such competition.

LinkedIn vs Pealk

Note: I’m basing my analysis on a TheNextWeb article which includes both sides of the story.


A small French start-up was cut off from using the LinkedIn API due to Terms of Use violations. The story gained a lot of buzz in the developer community, because many saw it as a breach of trust between developers and the SaaS company.  The LinkedIn response details why API access to the company was cut off:

LinkedIn confirms that Pealk was in clear violation of our terms of service, including:

– Storing/archiving LinkedIn profile data
– Using LinkedIn data to create email marketing messages to LinkedIn members in volume
– Creating competitive solutions to LinkedIn

LinkedIn clearly communicated to Pealk that they were in violation of our terms of service well in advance, and they were notified to remove their LinkedIn integration. [Emphasis is mine]

One of the reasons mentioned was the no competition clause. As one comment to the article suggests, this response was to be expected.

The strategic view here is that if you are positioning yourself as a startup to leverage LinkedIn’s API to provide competition to any of its existing paid products, you have to expect they will pursue action against you first and foremost through enforcing restrictions on the use of their API before they think about (usually) more expensive moves such as hiring/acquiring you.

Note: In past versions of the LinkedIn APIs Terms of Use, this prohibition was explicitly mentioned:

“Use the APIs in an Application that competes with products or services offered by us;”

This clause caused some headaches amongst developers. Curious is that in the most recent version of this document, this clause has vanished completely:


Twitter and its API

In June, Twitter changed the rules governing its API, became more restrictive and reinforced “acceptable” behavior on the part of its developer ecosystem. 

With our new API guidelines, we’re trying to encourage activity in the upper-left, lower-left and lower right quadrants, and limit certain use cases that occupy the upper-right quadrant.

/wp-content/uploads/2012/09/image001_138085.jpg

[….]

That upper-right quadrant also includes, of course, “traditional” Twitter clients like Tweetbot and Echofon. Nearly eighteen months ago, we gave developers guidance that they should not build client apps that mimic or reproduce the mainstream Twitter consumer client experience.” And to reiterate what I wrote in my last post, that guidance continues to apply today.

Through API-related changes, Twitter forced developers to move away from areas that threatened core Twitter functionality.

How might SAP respond to such competitive challenges?

Before we examine how SAP might respond to such challenges, it is useful to determine the probability that internal competition might occur at all

A quick overview of the developer ecosystem associated with SAP OnDemand offering shows that it is still very much in its infancy.

  • SAP’s OnDemand applications are largely created by SAP itself (SuccessFactors, EPM OnDemand, StreamWork, Travel OnDemand, etc) rather than by its developer ecosystem.
  • Although the developer ecosystem of the NetWeaver Cloud is growing rapidly, it is still very immature.  This PaaS environment is still in Beta and there are few applications running on it (The NetWeaver Cloud Portal is one exception).
  • The old idea of Core PaaS for LoB applications has disappeared robbing interested SAP developers of another way of creating OnDemand applications.
  • There is a vibrant ecosystem of ByDesign partners but how many of these partners are involved with GoLive support rather than the development of SDK-based add-ins?  Since the goal of such add-ins is to complement existing ByDesign functionality, it really isn’t possible to describe them as competition.    

So based on this situation, the discussion about competition is currently largely hypothetical but will be more relevant as SAP’s OnDemand offerings mature.

SAP’s OnDemand landscape isn’t monolithic and the offerings are quite varied. Accordingly, this risk of internal competition is different based on the offering in question.   There are various factors – ranging from technical architecture to market served – which influence whether internal competition is plausible.  One such criterion is the complexity of the application.   In the following graphic, I provide a few examples of SAP OnDemand offerings and their respective risk.

/wp-content/uploads/2012/09/image002_138086.jpg

For example, Business ByDesign is an entire ERP Suite and it is very unlikely that some partner can recreate this offering in its entirety. If you look at RecallsPlus, however, the functionality is much more restricted and a partner might more easily develop a competitive product.  There are other factors besides complexity (size of the perceived market, the perceived value of the functionality to the customers, etc) that influence a decision to create a competitive offering. My intention is to show that the competitive threat level for SAP offerings is different.

Note: Some might say that RecallsPlus isn’t a good example for competition but it demonstrates what Gartner calls SAP’s Nexus Strategy and will probably be a pattern  much repeated (and perhaps copied) in the near future.


Big fish eat little fish

Competition between a developer ecosystem and a SaaS application doesn’t necessarily mean that a partner copies the functionality of the SaaS application. On occasion, the company with the SaaS application discovers that a partner application has exploited APIs or other functionality and developed useful functionality that customers love.  In such cases, the temptation to copy such features may be great.  Therefore, it may prudent to read the Terms and Conditions of APIs that are used.  On example from the LinkedIn API Terms of Use demonstrates this potential issue.

LinkedIn Independent Development.

You understand and acknowledge that LinkedIn may be independently creating applications, content, and other products or services that may be similar to or competitive with your Application. Nothing in these Terms will be construed as restricting or preventing LinkedIn from creating and fully exploiting any applications, content, and other items, without any obligation to you.

I’d be curious to know if the ByDesign SDK Terms of Use include something similar to this clause.

MyTripAssistant vs Travel OnDemand:

In the future, what would happen if a partner application actually competed with an existing SAP SaaS application?  This hypothetical business case could occur sometime soon:

Business Case: MyTripAssistant

Company Name: Bob’s Best Apps

Development Expertise:

We have a variety of developers with decades of experience developing enterprise applications with Java tools and technology.

Regional focus: Latin America

Domain Expertise:

We have been developing travel-related cloud-based applications for the last 5 years on a variety of platforms. Please refer to our popular Heroku-based applications TravelExpenseKiller and MyTravelHelper.

Business Opportunity:

We have analyzed SAP’s Line of Business (LOB) OnDemand application Travel OnDemand  and have determined that a typical business user in our market only requires 70% of the functionality provided by this application. We propose creating a new application called “MyTripAssistant” to provide this functionality. 

MyTripAssistant could be seen as a direct competitor to Travel OnDemand.

In the past, I might have suggested that this application might have been developed for the “Core” PaaS that is used by other LoB applications such as Sales OnDemand, Travel OnDemand, etc. At the present, only the NetWeaver Cloud PaaS would be an option as a deployment platform for partners.

Chokepoints

What tools might SAP use to deal with this competition?

API

In the case of LinkedIn and Twitter, influence over competition was performed via the API of the applications involved.  If you look at SAP’s OnDemand offerings, there isn’t always an API that the developer ecosystem could use or which SAP could exploit. The ByDesign SDK is one exception. The SDK for Sales OnDemand appears to be in development but not yet released.  The HANA AppCloud-based applications (EPM OnDemand, SoP OnDemand, etc) don’t appear to have API that might be used to create competitive products. StreamWork has an API that is well-developed and its StreamWork API Terms of Usage contains the usual provisions.

5.9 Licensee acknowledges and agrees that Licensor may create, acquire, receive, technology, software, applications, content and other products or services (collectively, “Similar Development”) that may be similar to or competitive with the technology or products of the Licensee. Licensor is entitled to develop, create, and fully commercially exploit any Similar Development.

5.10 Licensee will not develop software that would compete or competes with any StreamWork Add-ons created, in whole or in part, by Licensor.

I assume that more interfaces will emerge (either in form of SDKs or APIs) as SAP’s OnDemand offerings mature and these interfaces will become possible choke points to prevent competition.

Certification

For some of SAP’s OnDemand offerings, certification of solutions is necessary for those applications to be sold.  I don’t mean verification of its technical quality (assuring that the application won’t detrimentally affect other tenants or applications, etc) but rather if the subject matter of the application fills accepted white spaces.

This is especially true for the solutions that run on shared environments such ByDesign and NetWeaver Cloud.  I’m sure that there is certification documentation for solutions based on the ByDesign SDK but I was unable to find it.  The NetWeaver Cloud is still too new and I doubt there are any details about certification.  

Since an application would have to pass through certification to become available for customers, this chokepoint might allow SAP to stop any application that posed a competitive threat.

Note: This chokepoint might not be used. If you look at the certification for Mobile Packaged Apps, the criterion are very straight-forward and allow a very wide range of applications. The difference here is that SAP makes the majority of its money from SUP and other platforms that run OnPremise rather than the Cloud. The business model for OnDemand applications is different and as a result, a more aggressive certification model might be used.


SAP Store

Unlike mobile applications which are “sold” on non-SAP controlled stores (such as iTunes and Google Play”, I assume that applications that run on the NetWeaver Cloud will only be available on the SAP store.  In this environment, a potential competitor might be blocked from customers. I assume that this might also be possible through the appropriate Terms and Conditions restrictions.

If you look at the current mobile offerings in SAP’s Store, the majority come from SAP (77 from 118). If you look at the cloud-related offerings in the same store, the majority of the offerings originates from SAP or are ByDesign extensions.  

Thus, I assume that the situation of internal competition has yet to arise. As the number of involved partners / developers increases, the chance of competition increases as well.  We’ll see how SAP responds to such threats as the popularity of the SAP Store increases.

Conclusion

In this blog, I focus on how SAP might aggressively respond to internal competition. This behavior doesn’t have to take place.  Like any company, SAP wishes to protect its investments. There is, however, a co-dependent relationship between an OnDemand company and its greater developer ecosystem – in order to expand, the application requires a vibrant ecosystem yet the ecosystem must respect the boundaries established.

The most important factors in this relationship must be honesty and precision. As blogger Anil Dash stated about the Twitter API change:

But to be fair, a valid annoyance for developers is that the communication from Twitter about these kinds of changes has been vague enough to leave them uneasy. Combine the tech blogosphere’s Law of Fail behavior with the tendency that crowds have toward assuming the worst rumors in any given situation must be the truth, and you have a recipe for panic.

Competition in itself isn’t a bad thing – it is when its definition is unclear that problems arise.  SAP’s relationship with its developers has been evolving and as it matures, difficult issues, such as competition, shouldn’t be avoided but should be dealt with in the open.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Tim Guest

    Hi – A very interesting post with some god points I think SAP should consider. What may happen, as has happened in the Business One area with 3rd party add ons, is that SAP may simply “Acquire” apps or Cloud Services rather than try to compete with them.

    (0) 
  2. Christian Happel

    Hi Richard,

    great post!

    The following is my personal view based on what I know. It’s not an official SAP announcement 😉

    I don’t think we will ever forbid a partner to build something using our SDK tools. Whether it’s with the ByDesign studio for Business ByDesign, or with SAP Netweaver Cloud, or on HANA.

    As long as the partner believes that he has a viable business case he can do whatever we want.

    So far in ByDesign we handled it in the following way: If a partner asked us if he should build a specific add-on we told him – to the best of our knowledge – whether or not this functionality was on our own roadmap. Even if it was he could still decide to build the same on his own.

    I think that’s the best way to do it: If he delivers a better version of something, maybe a more usable one, then he should do it.

    SAP can only be happy about that:

    1. It shows us that the platform is good and the partner will pay us for using the platform.

    2. If it’s an add-on we will get money through the needed user license, too.

    I don’t see mobile apps to be different. In fact for ByDesign I am even convinced that we should let partners build all future add-ons that can be used by our mobile player apps. SAP should only invest in framework and platform capabilities such as push notifications.

    (0) 
    1. Richard Hirsch Post author

      Christian,

      I like this approach and I especially like the reasons you give why SAP should be happy with such “competition”.  The idea that SAP should focus on the platform capabilities rather than add-ons is a good one and would really help the ecosystem evolve.

      D.

      (0) 

Leave a Reply