Skip to Content

Why Mobile Isn’t Getting Off the Ground… Faster

Today, my colleague Tobias Trapp wanted to try out the Android mobile app for SAP StreamWork. It turned out that there were several hurdles to jump before he could use it:

  • find the app (it’s not in the Android Market – someone found it in the SAP Store for Mobile Apps or on the SAP EcoHub)
  • get it onto your mobile device (not easy: The SAP Store for Mobile Apps uses Microsoft Silverlight, so it cannot easily be accessed from the mobile device; you have to use your desktop PC to request a download link)
  • download, print, and sign a two-page license agreement and send it to Canada via snail mail (no joke!)

I really wonder why it has to be so difficult for the Android version when the iOS version is simply available in the App Store and you can just install and run it without jumping through a bunch of hoops.

When Tobias showed me the freshly printed legalese he has to mail to Canada now, I didn’t know whether to laugh or cry. Compare this procedure to just downloading an app from the Android Market or App Store! If SAP is really allowing their legal department to make it so hard to use an SAP app, it’s going to be a long time until one billion people use SAP through mobile devices!

To be fair, someone from SAP responded very quickly to the criticism and explained that they agree that the current state of affairs has much room for improvement, and are working very hard to make these improvements happen. That’s good: SAP listens.
What else is good? They have a good technology portfolio for mobilizing enterprise applications, and SAP’s CIO Oliver Bussmann and his team perform truly groundbreaking work in adopting mobile in the enterprise. I believe that currently, nobody is better at enterprise mobility than these folks. They set standards with deploying and managing huge numbers of iPads in the enterprise, and are now the spearhead for the enterprise-adoption of Android tablets.

What is bad, and inspired this rant? Looking at the parameters for the wide-spread adoption of mobility at SAP’s customers made me feel rather glum. If my perception is correct, Mobile isn’t going to really get off the ground in the SAP ecosystem unless the following problems are fixed first.

Sybase SUP

To my knowledge, there is still no free trial or developer license of Sybase SUP. This means that as a consultant, or system integrator, or independent software vendor in the SAP space, you cannot build the skills you’d need to start developing solutions on top of Sybase SUP. I almost cannot believe this because I don’t know how anyone at all would be able to move into the field under these circumstances. Also, I don’t understand how any decision maker and IT strategist at a customer can buy the product without letting their own developers try it and perform a technical evaluation first.

In response to this criticism, Sybase representatives have promised that a trial or developer license would be released soon, and all I can say is, it’s high time. I hope it’s not too late.

NetWeaver Gateway

Fortunately, SAP is not making the same mistake. With a number of different programs, they are working hard to drive adoption by developers, and give everybody the chance to learn about Gateway by trying it out. You can even download a free trial version from SAP Community Network (SCN).

Gateway has, in my humble opinion, two problems:

1. Gateway should use the BOL but doesn’t

The first is a relatively minor flaw, and can easily be fixed – an important feature is missing. With Gateway, you can build REST/OData services on top of existing business objects, but Gateway supports only the very dated Business Object Repository (BOR) as a business object layer and not the state-of-the-art Business Object Layer (BOL), which evolved out of CRM but is now a cross-application tool that works well with Web Dynpro ABAP and Floorplan Manager  as well as several other frameworks. Gateway not supporting the BOL hurts both Gateway, which denies itself access to a wealth of SAP standard and customer-defined (or customer-enhanced) business objects, and the BOL, which is only inches away from establishing itself as the next business object layer in the ABAP world, and would profit greatly from the synergies with Gateway.

2. Gateway needs a pricing model that works for everyone

The second is a major flaw, but could also be easily fixed. Graham Robinson explained in his recent blog Thoughts on NetWeaver Gateway (Thoughts on NetWeaver Gateway) why the current pricing models have a hard time offering a sufficient incentive for app developers, independent consultants, and system integrators to use Gateway as a building block, or recommend their customers to do so.


It has been pointed out that SAP hasn’t developed a whole lot of mobile apps. They respond to that by saying: “The ecosystem will build them! We supply the infrastructure and tools.” Well, from a technological point of view, they have a solid toolset. Sybase, Afaria and Gateway, and SAP’s technology strategy in this field seem to work. But as SAP’s CEO Jim Snabe pointed out in a recent meeting with the SAP Mentors, it’s only innovation and it’s only even relevant if it scales, gets a wide adoption, and actually changes stuff in the real world. In order for that to happen, we need:

  1. low-barrier access to the software and training materials (I’m looking at you, Sybase) to quickly create a wide adoption by the developer community
  2. pricing models that create win-win situations by making it attractive for developers, customers, and SAP to use SAP’s tool. Especially the system integrators are a critical sales channel for SAP technology, so the pricing models should be so that they earn more, not less money when their customers license SAP’s tools.

Considering the importance of mobility in SAP’s technology strategy (it’s of their top three priorities), I don’t understand why it takes so long to fix these problems, which have been identified and pointed out by others months ago. In my opinion, SAP’s mobility strategy is not fundamentally flawed. Without changes at the fundamental level, it could be highly successful with some tweaking in the execution: If you’re going to rely on the ecosystem to build many mobile apps, create the conditions for them to do so.

You must be Logged on to comment or reply to a post.
  • As an independent consultant myself, I receive a constant stream of technical inquiries about SUP, by current as well as prospective customers.

    Since I’m highly focused on user-friendly mobile enterprise apps, I’m quite eager to get my hands dirty with SUP. A trial or developer license would be more than welcome!
    I am inclined to take the SUP courses, but without actual hands-on experience I’m a bit reluctant to pay €6K+ on course fees…

    In the meantime, unfortunately, I can only supply my clients third-hand knowledge about SUP

  • Thorsten,

    Thanks for writing this measured blog. I’ve tried a couple of times but have ended up with unpublishable rants 🙂 It’s not just mobile either. Almost every developer technology at SAP suffers from this problem. Even the developer/trial downloads available on SCN are often out of date and address only a small (but important) subset of the technologies SAP provides.

    The more I learn about it, the more I suspect that the problem is the level of control that SAP’s legal group exerts over product management decisions. However, being on the outside I can only suspect and not know. The only thing I can know for sure is that something is wrong and it is hobbling SAP severely when it comes to developer skills and interest.


    • Ethan,
      Thanks for your comments. Believe me, I was very tempted to return to the “Kiss of Death” scheme, but I learned that this will only keep people from discussing the actual issue at hand. 😉
      I agree with your analysis about SAP legal. I’m beginning to believe that this is a case of “the tail wags the dog”. If there are so many things other software vendors can easily do but SAP cannot, for legal reasons, are they perhaps living in a parallel universe with entirely different laws? Do they, perhaps, have too much of a “can’t-do” mentality? After all, I’ve seen it happen several times that when a C-level executive said “I want it done,” then it was done despite legal’s concerns and as of today, it hasn’t killed SAP. 😉 But C-level execs aren’t always there to override legal’s objections. I believe the company will have to find a more pragmatic way to handle legal risks.
  • If you check Gateway 0.5 release … they were gateway BOL models .. now the new tools generate something similar to BOL Objects but a more flexible…
  • Nice post.

    On BOL support, a little bird (and I don’t mean Twitter) tells me that this is coming in SP4, planned for sometime in 2Q2012.


  • Explanations on why the Android version of SAP StreamWork is so much harder to get than the iOS one can be found on the original post of Mr Trapp, and was posted yesterday evening: the Android version is only in beta (technical preview) and for this reason can not be distributed as easily as a GA product such as the iPhone version and the BlackBerry version.
    I sincerely hope that you will understand.
    Please let me know if you have any further question.
  • Well, IMHO SAP could make it easier to get a beta version. I don’t know about the reasons but I think that SAP Legal should be more pragmatic. Perhaps SAP CEOs should force SAP Legal guys to do their work with existing SAP products and official documentation. And perhaps SAP Legal will start to learn that their restrictions are neither seasonable nor reasonable. Sometimes I think that at the moment the unpragmatic and unworldly point of view of SAP Legal is a bigger threat to SAP than Oracle.

    But there is another threat: SAP speeds up and created lots of new technologies, platforms and solutions in the last time. SAP opened and verified the solutions with customers, partners, SAP Mentors and other people of the ecosystem. But now it is necessary that the rest of the ecosystem learns about the innovations: consultants, integrators and developers.

    SCN team and community do a great job sharing knowledge but this is not enough – SAP must not forget about the rest of the ecosystem:  freelancers, developers and system integrators which can’t learn how to use the mobile stack. An SUP developer license is a necessary step.


  • The problem with SAP AppStore is that is not an AppStore at all. It’s just EcoHub for mobile apps.

    What made Apple’s store work was in my opinion:
    – Clear advantages to the developer: A sales channel where all the billing is done by Apple. Great for independent developers who don’t have a backoffice (30% is cheap);
    – Purchasing is made easy: In my opinion the app market is making millions with low prices because it’s so easy to buy. There is a price, click a button, you the app.

    SAP Store is nothing like this. Apps that are not provided by SAP don’t even mention the price or the technical requirements, just a “Contact sales support” link. After I saw this, I just closed the browser window and dismissed the “SAP Store”.