Skip to Content
Author's profile photo Former Member

Project Santa: Developing mobile apps for multiple device types

At SAP TechEd Demo Jam two months ago we showed how we plan to make our consultants lives easier with mobile technology. The morning after demo jam I had a proper headache from celebrating our second place as well as an email inbox full of emails all asking: “When can I have the app?”

In the meantime we’ve kicked of Project Santa, which is all about driving efficiencies in the way we work. While the demo jam entry really was about floating some ideas and giving an impression of what a solution might look like, Project Santa makes those and other ideas reality for Bluefin. We’re going to use SAP’s planning tools for our resourcing process and a mobile application to make it easier to record time against projects.

In this blog series I’ll discuss some of the key challenges of the mobile application part of Project Santa and how we’re addressing them in our specific situation – clearly without any intention to provide universal or comprehensive answers.

Developing mobile apps for multiple mobile devices types

So let’s dive right into our first challenge, which is that we are faced with a wild mix of mobile devices. In a recent poll we found that our workforce uses pretty much any mobile device type out there: Android, BlackBerry, iPhone, iPad, Palm, Symbian, Windows Mobile, Windows Phone, etc. So how do you go about creating mobile apps for such a long list of target devices and be ready to support whatever comes next?

Catering for all of them seemed pretty daunting, but when we looked at the numbers in the poll we found that if we focus on just iOS and Android devices we can actually reach around 85% of our smartphone equipped workforce. That’s not bad for a start, so we decided to concentrate on those two device operating systems for now but with an eye on how we can expand the reach further.

Mobile platform or micro app?

I thought hard about using a mobile application platform like SAP/Sybase Unwired Platform or Syclo Agentry. We partner with both vendors, so have the knowhow in-house to build on their platforms. In my opinion however today’s mobile application platforms really shine when there is a requirement to build mission critical mobile applications that need to work without network coverage. This is understandable given that this is where the money was in enterprise mobility over the last ten years. I’d be keen though to see a more holistic approach to mobility that addresses the needs of small and complex scenarios for both internal and external users on a wide range of target devices. The recent messaging from SAP and other mobility vendors seems encouraging and from what I’ve seen so far they’ll make some major steps forward in 2011.

There’s nothing like the present though. The “lighter” approach available today is to write a mobile application that directly connects to the backend system whenever it needs to retrieve or update data. This style of applications is commonly called “mobile enterprise micro apps”, while SAP seems to prefer the term “mobile instant value applications”. The overall complexity of this paradigm is much lower and security doesn’t tend to be such a big issue as no data is stored on the device. The consequence obviously is that the application won’t work if there is no network coverage.

Our mobile timesheet can clearly be classified as a mobile enterprise micro app, but that still leaves us with the question of how we’re going to make it work across a number of different device types?

Cross-platform compatibility with web technologies

During the run-up to demo jam I also experimented with using web technologies wrapped up into a thin native mobile application to achieve cross platform compatibility. But let me explain this in a bit more detail…

All modern smartphone SDKs can embed HTML content into applications via a control. The idea is that a thin native app only has to start up the HTML pages that are also on the device in fullscreen mode, so that application development effectively comes down to writing HTML, CSS and Javascript. All that is then needed to port it to another platform is to re-write this thin native wrapper and package it all up again. Luckily the guys at PhoneGap have done much of the legwork already and also added access to many typical mobile device services like the camera, compass, geolocation, etc. In addition I’ve added jQuery to the mix for AJAX access to backend services and the recently released alpha version of jQuerymobile for a consistent user experience and to deal with the subtle differences between browser implementations.

The initial experiments were promising so we got together for a joint proof of concept coding session. The developers involved grasped the ideas of the framework instantly with almost no learning curve thanks to the familiar web technologies. Within a day we had a rudimentary prototype up and running – both on iPhone and Android – and three days after project kick-off a screen prototype was presented to the to the business owner. The project team is now heads down in development mode so I hope we can share some lessons learned in a couple of weeks.

Other challenges…

In my next blogs I’ll look at other challenges (e.g. mobile application deployment, user adoption, etc.) that we’re tackling as part of Project Santa and any lessons learned. Please do let me know if there is a certain aspect that you’d be keen to read about.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo John Appleby
      John Appleby
      I spent a lot of time talking about this approach yesterday at the SAP Influencer Summit and what you're doing is a clear sign of what is coming in the market.

      The Project Gateway platform looks like it will provide a proper platform that will give RESTful Web Services, so in future we won't have to write our own Web Services code.

      But on device, the SAP roadmap shows that HTML5 will be a great way to generate apps for multiple devices - when support of multiple platforms is more important than tight usability.

      So I'm excited to be a user of this solution when it comes and looking forward to more details as it progresses.

      Also to the readers, they may want to check our COO's blogs on this - Philippa Holland, who is blogging on her Bluefin website blog. Pip blogs from the business perspective, it's good reading.

      Author's profile photo Paul Snyman
      Paul Snyman

      Nice article and thank you for sharing all of this, I was also impressed by your demojam example.

      It appears the there is a market need for frameworks such as jquerymobile, have you investigated Sencha yet?

      On the backend side I think were all anxiously wait for Project Gaetway to become openly available, I think SAP would be well advised to not charge additional license fees for this ABAP add-on if they truly do want to drive fast paced adoption of On Device.

      Keep up the good work,

      Author's profile photo John Appleby
      John Appleby

      Well it's interesting because Project Gateway isn't confirmed as a separate product or an ABAP Add-In. I also hope that it won't require an additional server, that would be a disaster. I'm hoping it will be like the ES bundles for ERP 6.0.

      It definitely will require license fees although the model is unclear. If SAP are smart they will provide a consumption-based model, which will allow them to charge on usage, meaning you can have a very large number of users without linear pricing. But nothing has been announced yet unfortunately.



      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Thanks Paul and John for your comments!

      I've experimented with Sencha before jQuerymobile was released but found it much harder to use and struggled finding decent documentation. That might be different by now though. Have you used it or any similar frameworks?

      I am also curious to see what Gateway will bring, but I'd also say let's get going with what's there today. Writing RESTful services isn't that hard for a skilled ABAPer, so why wait if we can get the benefits now?

      Also I am sure there will be a license fee involved for any users connecting to the backend system via Gateway - just like today - but SAP needs to come up with a more flexible model than what currently exists to boost uptake. Something aligned with the actual usage / value obtained would make sense.