Why Mobile Isn't Getting Off the Ground... Faster

former_member182046 · ‎01-12-2012

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.

Conclusion

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:

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
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.