Recently, Sanjay Poonen wrote a blog about his vision for mobility, and COMPUTERWORLD published a related article, “SAP Aims to be the Apple of  Enterprise Mobility”. To see how we can turn these visions into reality, I’m going to delve one level deeper and focus on the SAP Mobile Platform. This blog is focused on business-to-employee (B2E) apps.

When Sanjay asked me to join product management for the mobile platform, the first thing I did was ponder what mobile actually means for the enterprise. How is it different from Apple apps and iTunes? In the spirit of true design thinking, Stan Stadelman, from product management, and I whiteboarded how enterprise mobility should work and what a platform’s role is in that picture. We also compared enterprise mobility to the gold-standard of a mobile experience – Apple.

Why Do We Need an Enterprise Mobile Platform?

Apple doesn’t sell you a mobile platform, yet, via the iTunes store, it enables the roll-out of business apps, like Tripit, to millions of users. Granted, I need a development environment to create apps, but if I don’t want to develop apps myself, I don’t need Apple’s xCode. So why do I need a platform in the enterprise world? 

When we look a little closer at enterprise mobility, we see that there are more challenges than in the Apple example. Here are three obvious challenges when you “go enterprise”:

  • Cross-Platform: Apple has only one operating system, iOS, but your enterprise will have to deal with more than iOS and cater to Android, Windows, BlackBerry, etc.
  • Backend Connectivity: While you and I will run Tripit against the same hosted backend, an enterprise app needs to run against your company’s backend (e.g. a customer relationship management (CRM) app needs to access your customers in your CRM system; a leave request app has to run against your own ERP).
  • Security: An enterprise app needs to adhere to your information technology security standards as employees will access your corporate data from the wide open internet – and you will want your business data to be safe.

Yet, the end user expects an Apple-easy experience – without virtual private networks (VPN), the need to enter backend server strings, or prompts for a username/password. Whether users download Tripit, Angry Birds, or your company’s leave request app, they should be able to click on the app to run it. The user expects all these apps to function the same way:

3 apps.png

Graphic 1: mobile apps

This is where the mobile platform comes into play. It takes care of the enterprise challenges such as cross-platform, backend connectivity, security, and much more – to keep all of this complexity away from the end user and keep things Apple-easy.

So let’s dive in…

In the following we will discuss

  1. the constituencies of a mobile platform
  2. what the term “mobile app” means to each of these constituencies, and
  3. finally we will put it all together into one end-to-end story highlighting the benefits of the platform for each constituent

Mobile Platform Constituencies

To define the platform correctly, we need to know its constituencies – and we don’t have to look far – SAP’s vision for mobile states them:

1,000,000 developers, 10,000 customers, a billion users

So our constituencies are:

  • Mobile App creator (designer / developer – be that SAP’s own apps teams, customers or partners or individual app developers)
  • Enterprise customer (administrators / procurement / the business or Line of Business)
  • Enterprise user or employee

A successful platform has to cater to all 3 constituencies and their respective mobile app needs

  • Create
  • Manage
  • Consume

And it seems intuitive to center the user experience of a mobile platform around the “mobile app definition” (as opposed to e.g. security profiles, landscape definitions etc). That begs the question:

What is a mobile app?

For the user, that question is easily answered: it’s that little icon on their phone: the Angry Birds, Tripit, or Leave Request

For a developer, that notion of an app is not enough. For a developer, the icon (actually the binary) is just one part of the app – and there might be multiple binaries for an app (one for Apple, one for Android, one for Windows etc.).

For a developer an application is a collection of multiple app components:

  • Backend models (e.g. ABAP code in an SAP ERP system)
  • Service documents and APIs exposing functions
  • Metadata such as style-sheets
  • The different native binaries or HTML5 code along with
    the respective web containers for the different operating systems

mobile app.png            

Graphic 2: mobile app components

For the Enterprise the picture of what an app is becomes even more extensive.

For procurement an app are all the different software components described above that the developer creates, but for them it’s also the licensing info associated with it.

For the enterprise administrator, it’s all the above mentioned components plus the enterprise specific items that need to be in place for an app to function in an enterprise. These items include: security policy for the app, user permissions, push notification configuration, custom branding and enhancements etc.

So as you can see, from this discussion, while the notion of an app is very intuitive (the icon on my phone) there is a lot more to it and it’s not trivial to make an app work in the enterprise for thousands of users. It’s like the classical iceberg – there is more to it that what meets the eye:


Graphic 3: enterprise apps – there is more involved than what meets the eye

It’s the mobile platform’s job take care of the items “below the water line” and to reduce this complexity and make things simple again – and Apple-easy for the end-user.

How things should be… End-2-End Platform experience

So what is the overall mobile platform experience supposed to be? What does “Apple for the enterprise” look like? Let’s take a look:

Create the app (Developer)

It all starts with the app creator – be that an individual developer, a customer who wants to develop an app, a partner – small or large – or the SAP app development teams. There are two distinct cases:

  • Development of a standard app to be sold (e.g., via the SAP store)
  • Development for a specific customer to solve a specific problem

Let’s discuss the case of a standard app that is to be sold to multiple customers.

A developer will need “vanilla” backend systems to develop against. Ideally the platform infrastructure allows him to commission backend systems (e.g. SAP ERP or CRM) in the cloud along with a service to expose the relevant services and data easily (e.g. via SAP Gateway). The developer will want a variety of tools at his disposal to create the different parts of the app we mentioned above:

  • Backend models and connectivity services
  • APIs exposing backend functions as services
  • business logic
  • WYSIWYG UI design tools for native and cross platform

These developer tools should provide a variety of functionality that take care of the enterprise features and thus allowing the developer to focus on the development of his app. These functions and services include:

  • Logon module to allow for various authentication methods and identity providers (SSO, Siteminder, Kerberos, certificates etc.)
  • offline and sync engine
  • Push notifications
  • Connectivity and data modeling tooling
  • Business logic modeling
  • Device simulators for the different platforms
  • Testing and simulation tools across all components
  • App telematics to capture usage stats of the app at a feature function level
  • Container for web apps for all platforms
  • Sample code and building block for services such as geo-fencing
  • User Interface building blocks
  • Access to phone peripherals such as camera, GPS
  • LCM support such as versioning and transports across the different components
  • Customization and extensibility framework for UI, business logic and backend model
  • Troubleshooting and debugging capabilities across the different components
  • Support of team development – multiple developers working on the same app
  • localization – regional and multi-language support

To give the developers choice of tooling, these services and functions should be delivered as plug-ins into the different design and development tools such as:

  • Native app development tools, e.g. xCode, Visual Studio
  • UI tools such as Sencha, Appcelerator or SAP’s UI5 designer
  • Eclipse
  • Backend ABAP designer for SAP applications

Once the app is developed, a developer will want to monetize it via the SAP store, which allows the developer to sell his mobile app around the world without having to establish a sales force in every country. He will also be interested in license and app usage reporting. All of that should be provided by the platform and the SAP store.

In the case of development for or by a customer some of the services are slightly different:

  • Usually there is no need to commission a “vanilla” backend to develop against. The customers development landscape can be used instead
  • There is no need to push the app to the SAP app store
  • The need for customization and extensibility frameworks is lessened – as the customer owns the source code of the app itself

Manage the app (Administrator)

The whole enterprise administration of the app is really the step that does not exist in the Apple world – but it is critical for the enterprise (see here). As mentioned in the intro, there are at least 2 things an admin has to do even in the simplest of cases: he has to connect the app to your own backend and he has to establish a secure user authentication in line with your IT security policy. But that is only the simplest of cases. There usually a lot more to it – e.g. the management of apps across different operating systems. In addition, the administrator has to handle and merge 2 lifecylces:

  • The lifecycle of the standard app that the developer / vendor upgrades over time
  • The lifecycle of his customizations and configurations to the standard app to make it work in his enterprise

So let’s look at what an enterprise admin would expect from a mobile platform. The administrator has 2 main jobs:

  • Get the apps going – initial roll out
  • Keep the apps going – sustained operations

The platform has to address both items and ensure that the initial roll out of applications to thousands and sometimes tens of thousands of users is cost effective. Consultants are usually expensive resources and customers don’t want to keep them around forever to get apps rolled.

Almost more important though is the operations of the apps – ideally no consulting help is needed and operations can be moved to lower cost resources.

So, what does the platform have to offer to help with roll out and operations –

  • Simple way to connect the mobile app to the customer’s backend(s)
  • Security and Authentication: Siteminder, Kerberos, SSO, certificates, SAP portal integration, oAuth, SAML
  • E2E tracing, debugging, root cause analysis, troubleshooting tools for quick root cause analysis – superior error-messaging
  • Ticket system integration (API) to allow users to automatically submit all the information (stack trace, logs, screenshots) in case of an error in the app without emailing or manual intervention
  • Usage reporting and analytics by user, device, app, vendor, region etc.
  • Onboarding tooling – allow sending of server strings and logon information to the app on the user’s device without having the user enter it
  • Versioning, lifecycle management and transports of all component of the app across the development, test and production landscapes
  • Extensibility and customization of standards apps purchased from the SAP store
  • Easy upgrades and backward compatibility – server upgrades should not impact the running apps and app upgrades should not require server upgrades
  • License management
  • Scalability & Performance – clustered or federated landscapes, high availability
  • Content management and image processing
  • Data integration, orchestration, and connectivity to SAP and non-SAP systems to facilitate end-to-end scenarios such as order-to-cash or procure-to-pay
  • Support for testing – e.g. via automated testing where you define the test case  and specify for how many users/ devices across what regions this test should be run to simulate realistic loads

All of these services are designed to reduce the cost of setting up and running the applications.

But there are request for more advanced features such as

  • App-to-app integration – as an enterprise you know what apps are on a user’s device so app-to-app integration is possible. E.g. accessing the pricing app from the CRM app – passing the context from one app to the other
  • App wrapping to allow you to manage any apps – not only the ones built on the platform
  • Control app behavior in user specific or role based context – e.g. only allowing certain employees to use the camera feature
  • Social media integration

mobile cloud.png
Graphic 4: mobile platform in the cloud – admin console

Consume the app (End-User)

Well, this one is easy: user downloads the app and starts using it. All onboarding, app registration and bootstrapping is done by the platform: server strings, logon information or certificates are pushed to the user’s device without the user having to do anything – Apple easy!

In summary we have 5 steps:

  • Developer creates app and publishes all app artifacts (front-end and back-end) to SAP app store
  • App gets certified and developer gets set up to receive payment for each sale of the app via the store
  • Enterprise procurement purchases app artifacts and licenses from the SAP Store
  • Enterprise administrator configures and customizes the app, transports it thru the system landscape and pushes it out to his users
  • End-user gets the app, he is onboarded to the app without having to do anything himself and he starts using the app

apple of enterprise.png

Graphic 5: end-to-end picture of an enterprise mobile app – Apple for the enterprise

That is what I would call “Apple for the enterprise” – that’s the goal that keeps me going everyday as a product manager for the SAP mobile platform…

Further information

For live updates on all things SAP Mobile, follow me on Twitter @jenskoerner

Looking for SAP Mobile demos, customer references, roadmaps, performance and sizing information, training, documentation or tips & tricks?

Check out Jim Jaquet’s interview with me at SAP TechEd in Madrid

Carolyn Fitton’s blog 3 reasons why developers use SAP Mobile Platform to create enterprise grade apps

Watch Kevin Benedict‘s Mobile Expert Video Series

Sanjay Poonen‘s keynote at Enterprise Mobility. At minute 44:01 we are demoing the platform

Carolyn Fitton‘s blog 3 for 1: SAP Mobile Platform Meets 3 Different User Group Requirements contains 3 videos that provide a great overview of the value of the mobile platform.

To report this post you need to login first.


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

  1. Bjorn Vilhjalmsson

    Good arguments for a platform and SAP is progressing well towards having delivered most of these already.  With regards to platforms for B2E apps, most companies are not going to afford to support all apps on all main platforms (iOS, Android, Windows Phone, Blackberry) while still providing the experience that end users expect (native type of performance and behavior).  I expect most companies to support mostly 2 platforms and it remains to be seen if windows is going to be one of those or not, the obvious choice today is Android and iOS. 

    I also see the portal making a type of a comeback now with portal on device possibly becoming an option.  Despite all the focus on mobility I don´t see the PC and PC browsers going away in the near future and the portal might just be the easier and cheaper option to build a better user experience/interface for both PC and Device which the casual end user has been demanding for so long. 

    A very important part of SAP offering in mobility is around mobilizing not just SAP data but data from any source.  Platforms that only mobilize a single backend are not a very smart solution IMO for most companies. 

    1. Jens Koerner Post author

      Hi Bjorn,

      I agree with you re non-SAP data. That’s why I listed “Data integration, orchestration, and connectivity to SAP and non-SAP systems to facilitate end-to-end scenarios such as order-to-cash or procure-to-pay” under the bullet list for the administrator. The format got a bit scewed so I’ll fix that. Hopefully that addresses your last sentence.

      Re the number of platforms that a company supports – any company that allows BYOD will have to deal with all platforms. SAP IT for example has to handle all OS platforms for us. So, a mobile platform is there to make their job easier.



  2. Graham Robinson

    Hi Jens,

    thanks for this blog – it makes a clear case for a mobile platform.

    Can I ask you to comment on the difficulties of cost justifying such a platform?

    I usually find that my customers are advised to start small. Identify a single business case that can be improved with a mobile app and use the experience of building, deploying and supporting that app as learnings before choosing the next business case for mobilisation.

    The problem is that it is very difficult to justify the cost of a mobile platform for a single app – or even for three or four.

    From your experience when do customers find suitable benefit from a mobile platform to be able to present a successful business case for one? And how best can such a business case be presented?


    Graham Robbo

    1. Jens Koerner Post author

      Hi Graham,

      here are some answers:

      – cost: we are planning on coming out with a cloud version of the platform that will make the consumption much more effordable – especially when starting just with one or two apps. For on-premise, we started bundling the platform with other services such as Gateway to make the pricing more attractive.

      – business case: here is one of my favorite examples that a customer shared with me at SAPPHIRE:

      If I had great end-to-end tracing capabilities via a platform, then I could avoid having expensive consultants poke around for 2-3 days to find an error with an app. Instead we could leverage much cheaper support staff to fix the error in a matter of hours. This reduces my support costs significantly.

      Hope this helps


    2. Gavin Quinn


      I like the idea of starting small. At we have been building pure html5 web applications directly on the existing sap ecc or portal platform, allowing a company both to start small, and not invest in a new platform.

      I would be curious the success rate of the SAP App Store. Does anyone have any usage statistics from it?

      I think if you really want to invest heavily in mobile and offline capabilities and cross-platform, then maybe Sybase makes sense. Thanks for the blog, it was very helpful.

      1. Jens Koerner Post author

        You nailed it Gavin: Think Big – Start Small and Fast!

        While a platform has its benefits, I understand that a company may not want to invest into a platform right away – especially if they are starting small.

        One way to use a mobile platform without the need invest heavily is the SAP Mobile Platform in the cloud. It provides the benefits of a platform without the upfront investment.

  3. Michael Bestvina

    I share with you your vision of the “Apple of the Enterprise”. However, the problem is that I think some of the focus is wrong areas in order to do this.

    Where possible, the tools to reduce as much friction as possible to the developers. Barriers are what cause projects to spiral out of control.

    A couple of ways to do that:

    1. Clean up the documentation. This needs fixing badly. Want to see good documentation?

    2. Make it less hard to download and update tools. Better package managers would be a first step. I still can’t find out to download the latest version of SUP on Service Marketplace.

    3. “WYSIWYG UI design tools for native and cross platform apps”

    I don’t think SAP should provide WYSIWYG tools for cross platform design. Leave this to the Appcelerator and PhoneGaps of the world. Focus on what you do best – connecting and managing the data layer.

    4. Pricing – I don’t have a solution for this, but the whole pricing model is not only not working for customers right now, but dually it’s extremely confusing. Either simplify it (even if it’s not right) or get it right and make it uber complicated. Pick one or the other.

    5. Last but not least. It’s taken me roughly 3 months now to find a solid technical contact at SAP to explain to me really the benefit of SUP (now SMP) from a technical level. Telling me it “can connect to any database, any source, etc” is complete gibberish to a technical person. We know this is sales speak (and that’s fine). Bolstering your CSA team would really help.


    1. Jens Koerner Post author

      Hi Michael,

      glad you like the vision. I answered some of the questions below – keep in mind that what I outlined in the blog is a vision, and while many pieces are in place, I’m not claiming that everything is perfect, yet:

      1.) yes, we heard documentation a lot. Our documentation team is on it. Along with that we are also looking into upgrading our training material and add more how-to guides to the developer corner on SCN. Let me know what you think of the SUP 2.2 documentation.

      2.) go to -> Installations and Upgrades -> Browse our Download Catalog -> Sybase Products. There you find all the platforms listed.

      3.) We are supporting Appcelerator, Sencha, PhoneGap etc. But with the push towards UI5 in SAP we are also providing our own UI5 tooling in App Designer. See TechEd keynote by Vishal Sikka for a demo.

      4.) Pricing – we are working on simplifying it. We got a lot of feedback and are planning on bundling components together in a logical fashion to make it easier.

      5) Hopefully this blog provides you a clear statement of where the benefit of a mobile platform is. With respect to CSA/RIG team – they are definitely getting bolstered. Talking to them frequently.

      hope this helps


    2. Annette Bater

      Hello Michael,

      My name is Annette and I’m part of the Knowledge Management team for SUP. I’m currently engaged in customer-focused research for our team. I would love to take a moment and follow up on comments regarding the documentation. This research in in its infancy, but would like to understand your mental model and interactions with our information delivery system as part of this analysis.

      Can you reach out to me via email and we can figure out next steps from there?




Leave a Reply