Skip to Content

Mobility continues to get lots of attention in the market place and I have noticed that what people mean by “mobile” varies from organisation to organisation and department to department.

A department that is responsible for a large team of service engineers will have a very different set of mobility requirements from those of a procurement department that is trying to speed up the approval process for purchase orders (just two examples).

These different mobile application requirement can be visualized in the diagram below for an SAP customer :

Mobi Cube.jpg

So this gives me 8 different types of mobile application :

  • SAP – Web App – Online
  • SAP – Web App – Offline
  • SAP – Native App – Online
  • Non-SAP – Native App – Offline
  • Non-SAP – Web App – Online
  • Non-SAP – Web App – Offline
  • Non-SAP – Native App – Online
  • Non-SAP – Native App – Offline

The question now, is do I solve all of these types of apps with one technology pattern / platform ?

To help answer this, I thought it would be useful to breakdown the mobility platform problem in to 6 different areas and consider which “layers” would be required for each application type. The 6 logical layers are shown below.

Mobi Layers.png

To make the blog easier, I am going to remove the SAP/Other category as this really only involves the Connectivity layer – let’s just assume that any backend system we have can be exposed as either oData or JSON (or pushed through a Gateway like product to convert from other formats to these mobile friendly ones).

So the next layer is Persistence / Caching, which really comes into play when we need off-line apps, important for Service Management type apps that need to function with no mobile signal, but less important for look up or approval type apps which tend to be more “of the moment” apps (not always true as we have approval apps that work off-line for approval in the air). This layer is supported by SAP Mobile Platform (on premise) but not currently by the SAP Mobile Platform – Cloud Edition.  It is my experience that many people believe that they need this feature at the start of their mobile journey, but they find that most of their apps don’t need it (or can work with simple store and forward methods).

The next layer in Security / Encryption, this is an obvious requirements where corporate data is concerned and I know many organisations that have the capability to build this layer themselves, often piggy backing on existing infrastructure used for laptop connectivity. What the SAP Mobile Platform does here is shrink wrap this layer so that if you are not a security expert you can get up and running quickly. This is true of both the On Premise and Cloud Editions (although they solve the problem differently).

Next we get to Application / Device management, a layer that is often seen as over kill when you are deploying your first app to 10-100 people in a proof of concept (but even here it does add a lot of value). You really need this layer as you scale your mobile usage as it will allow you to control who gets which apps (important for managing licences) and which data is left on which devices (important for security). So whilst you might not use if at the start of your journey, you should have plans to get this layer in place. SMP has good support for this in both the on premise and mobile editions.

The penultimate layer – Apps Development is where the rubber hits the road for any developer with the key questions being, which devices are supported and how much support does the application development framework provide ? Support for fast development of HTML5 apps is a must have, plus support for device specific API’s for native development. Many also offer an application builder capability (like Syclo Agentry) to support write once, deploy to many scenarios. This is an important layer if you want to develop your own apps, as the perception of the platform will live or die based on how quickly results can be produced. SAP UI5 (and App Designer) and Syclo Agentry are having a big impact on the capabilities that SMP can provide.

The final layer in my model is the Packaged Apps / Eco System as many organisations don’t want to write their own apps, but use those written by Software houses. The SAP Store currently has 194 mobile apps with about half from SAP – I would expect more news in this area at SAPPHIRE in Orlando.

As for SAP products to consider when thinking about mobility I would include :

The mobile platforms are obviously designed with mobility in mind, so you will find all the features you need in them (accept caching for the Cloud Edition for now). The other platforms can be used for mobile, but have a more generic use-case, so you might find yourself building some of the layers yourself.

To report this post you need to login first.

2 Comments

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

Leave a Reply