Skip to Content
Author's profile photo Matt Harding

An Overly-Dramatic (but possibly realistic) View of Mobility


This blog has been at 70% complete for over 6 months and sitting on my Google Drive just taking up space that I’m sure Google needs.  So with that in mind, I’m pinning this blog to this date with the aim to let you know how I go on on completing this journey in a future blog.

A Logical Architecture for the 21st Century (or at least 2012)

While not professing to be a mobility expert, I made a new year’s resolution to get a mobile application live this year somehow because since showing everyone how easy it was to do HTML5 offline mobile applications hooked up to an SAP backend way back in 2010 DemoJam, I’m continually frustrated at how difficult it seems to get anywhere in an Enterprise doing this for many different and sometimes very valid reasons.

In order to kick off the discussion, I’ll introduce something I’ve been toying with in my head to describe mobile applications from a conceptual application architecture perspective (which could apply to modern web applications too potentially).  Here it is:

In short, Mobile Device (or Internet Browser for web applications) is an obvious logical component that is composed of a rendering engine (for simplicity, this also includes managing client logic in this case), device security (since mobile devices can easily get in the wrong hands) and application storage (for storing cached content at a minimum but for potentially offline content as well).

The Application Content conceptual object is purely where we retrieve the relatively static application content from (but could include additional web content management content such as news, etc. It could effectively be the App Store in the case of a mobile app.

The API or Programming Interface is how we talk from the mobile solution to the back-end conceptually.

Hopefully we all know what back-end systems are…

Lastly, the deliberately thickly displayed foundation behind all of this is the core security bits like authentication, authorisation, device management and network security.

At this point, that picture is probably the best thing to take away from this blog. The rest of this blog really just captures my thoughts on some of the challenges that need to be addressed.  Hopefully this helps you as my new year’s resolution is definitely going to have to be delayed based on my current activities, but if you can say this helped you get something live this year, then I’ll take that as mission accomplished (kind of).

Security is Hard and Usually the First Step

Security requirements are usually  linked to policies initially.  For example, you may need a password to unlock the device. Possibly you also need dual factor authentication, but maybe the physical device is considered a 2nd form of authentication for registered devices. Alternatively you need to deploy client side certificates on the device to help with providing this dual factor authentication.  On top of this, network zoning models then may require the introduction of multiple tiers of security like reverse proxies, firewalls between different network zones, etc.

Whatever your policy ends up being, unless you’re offering a simple internal Wi-Fi only browser based option, the solution is hard to implement.  This is where Afaria and various other SaaS solutions that telecommunications companies are rolling out partly comes into the picture.

Unfortunately, my knowledge of getting this most fundamental solution pieces in place is the one that stops me going much further in a real enterprise but typically the requirements are something like:

For Internal Users:

  • Registering of tablets and smart phones.
  • Enforcement of policies on devices like password protection, secure storage for applications, signing of waivers to allow remote wipe if the device is lost, etc.
  • Provisioning of applications and their settings (such as SUP)
  • Set-up of VPN software or proxy configuration
  • Plus, I’m sure, lots more.

For External Users:

  • Really this requires a threat assessment to identify how much effort is involved and how many short cuts can be taken, but at the very least we are typically going to require some type of authentication mechanism, and if we are talking about customers/consumers, then we’ll also want some way of remembering credentials assuming we are not providing super sensitive information (like bank or health information) – For example, “I trust my device and I don’t want to enter a password every time I access facebook”.  No matter how hard your security team tries, unless you are a bank, external customers will see Facebook logins as a do once affair and think that is the way you should work.

In terms of internal users, this should be at least a well known problem to design for. But for external users like customers accessing their utility accounts held within ERP; I haven’t come across any single pattern that works in an enterprise context yet (Or at least that is supported by a typical enterprise security team).

It’s at this point, a famous saying that was coined within my engineering buddies come to mind.  It was a time when one of my engineering friends (who was a bit slack within a subject he didn’t care for) was asked to see the University lecturer only to be told “You need help to pass”! Now we use that term whenever we see a person who is unlikely to succeed without help.

So with that in mind, I throw down a challenge to SAP – I challenge SAP to write up a step by step guide to:

a) Getting an Enterprise grade SSO solution working in an Internal BYOD scenario to an exposed Gateway service with Afaria or similar (let’s go beyond Syclo or SUP at this point); and

b) Getting a long-lasting “remember me” authentication for untrusted external user mobile devices that can access SAP data via Gateway.

After this, our community security specialists will most likely provide feedback to see how these solutions stack up in the real world.

Oh and an important requirement is to not ask us to buy and/or install another 3-4 tier landscapes just so we can support these scenarios!

Outsourcing and Off the Shelf – The Killer Combination

Now to the next roadblock on our journey to mobilising our workforce. Mobility is kind of risky with lots of unknowns. Security aside, the risk is actually pretty tiny, but the unknowns are large and asking an outsourcer or system integrator of any kind to do a standard waterfall implementation of Mobility is ludicrous when everyone (including the business) is just coming to grips with how it may actually work and the business is thinking about how this may radically change their own industry without seeing it in action first!

Maybe we can avoid the unknowns by buying off the shelf?  But does off the shelf really work in an on-premise SAP world that is tailored to suit the business?  Maybe for specific scenarios but even then, I think about timesheet requirements at my current customer which just really being enhanced and not customised… All of those mobile timesheet, off the shelf Apps surely won’t work as expected without modifications here???  Even if it does, then how do we avoid a disjointed mobile experience with lots of tiny apps? 

For me, mobility is forever changing – but let’s get started with some baby steps (A.K.A. A more agile approach) and learn on the way.

Throw the Business a Bone

Mobility is the only way in 2015 according to one of the SAP CEO’s (can’t recall which one sorry). So if that is the truth, how come I still hear very little about success stories with Mobility beyond the SAP CIO, a Syclo/Sybase account rep or from a specific app (I didn’t research this much by the way but I shouldn’t have to right)?  Hopefully some ASUG stories may come out of the woodwork this TechEd???

But regardless, let’s make a big assumption that you’ve got SSO and security policies on your BYOD devices.  Big assumption I know. But if you have, how about whipping together an HTML5 app using Gateway, hosting the HTML on the DMZ exposed Gateway ICF node and addressing a key pain point scenario with Mobility?  It’s really easy if you’ve done any HTML/CSS/Javascript but even if you haven’t, the web developers probably aren’t far away to help you here (besides, that is the point of Gateway isn’t it)!

The point being – Give the business something so they can get their head around it and while you don’t want adhoc solutions getting out of hand, do something!  Please!!!

Licensing and External Users

You would probably think that exposing a mobile app to a customer is a great idea; but did you realise that there is very likely to be a licensing issue here.  And not necessarily a small one!  Now as much as bad things are said about Gateway licensing (and I still think we shouldn’t pay for Gateway for already licensed SAP users); it is an easy option for getting external users access to your systems (though you obviously would need to confirm the specifics with your account manager as I don’t speak on behalf of SAP).

Offline Capabilities or Online

I still look back at the DemoJam video Al Templeton and I did back in 2010 and it’s all still very relevant.  Tasmania being one of the most connected places on the planet by the end of this year, but there will always be gaps in communications even near city centres! ” Unless you are within an extremely well connected scenario with perfect connectivity; offline is important for mobility scenarios to make a real difference.

But even if it is not, if you develop HTML5 apps, build the content as a cached/offline app (search on the words “HTML5 manifest”) in order to make a web app that performs almost as well as a native App.  It works kind of like those Demo’s that Shai used to at TechEd on stage with Jeff where everything somehow seemed to respond in milliseconds! But it really does!


Native, web-based or combination

Here’s where I would would split external versus internal users.  External users can really benefit from a native app both from a security perspective, and usability perspective.  Marketing usually are associated with these budgets so at least you won’t have a problem there as native will typically cost more if you target multiple O/S and device screen types. 

Internal users though? Well, you’ve got a lot more control here so maybe a cached HTML5 web app is the way to go, especially with a BYOD policy in place.  And if you want to get fancy and leverage more device specific functionality, there’s always PhoneGap to wrap your app in.  That said, HTML5 device API’s are improving constantly and removing this gap.

October 2012 – Pinned

Well as I said above, I started this blog back in March and never got around to publishing it till now. Looking back at New Year’s resolutions, like you normally do, I can’t see me getting a mobile app live before the end of the year.  That said, I have hope and am positive that I will finish this commitment in the following 12 months as my current customer is taking all the right steps to get the foundation in place to enable the business.  All I can say is…Yay!…Finally someone is taking the importance of Mobility beyond just the hype and we’re starting to see the hurdles to jump with Syclo and SUP.  Once I have some decent answers (some which I hope to get extract at TechEd in a couple of weeks) and have “seen the light”, I’ll let you know how it all went and the lessons learnt.  Right now though, I still haven’t seen how that foundation layer will work so guess which step I’m at?…Yep – I need help to pass!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Tom Van Doorslaer
      Tom Van Doorslaer

      I think the phrase "possibly" in the title is not necessary.

      A lot of businesses struggle with the question how to go mobile.

      Especially the security question is a very vital one. You can explain all security measures over and over again, but someone will always find a hypothetical situation in which it can go wrong. Truth is, there is no waterproof solution. Not for mobile, but also not for the bolted down desktops.

      Moreover, if you want all these minimal security measures, you have to dig deep in your pockets. A company that has a vision and strategy on its people can justify the investment. A company that only looks at it's profits,... no.

      Really good article Matt.

      I read it in chunks 'n bits in between meetings, so I'll re-read it again as a whole, this evening. *Bookmarked

      Author's profile photo Matt Harding
      Matt Harding
      Blog Post Author

      Thanks for the feedback Tom. You may be disappointed reading it as a whole as I tended to write this very piecemeal, hence why it never really got completed till I forced it to be (and probably why it's more realistic than dramatic).

      Interestingly enough, the way that SCN/Jive does it's mobility SSO uses the approach of requesting a special pin similar to Google device passwords with the option of disconnecting the security remotely.  Pity I can't see any offering from SAP today that allows something similar for users like Utility customers where this is possibly sufficient???



      Author's profile photo Former Member
      Former Member

      Good read, thanks for the contribution. 

      With Mobility the real trick is to provide the balance between usability and security, badly implemented security policies will just lead to lack of adoption and a lost opportunity for the business, especially with a BOYD policy.  I have first hand experience where my own device had to get software installed (virus checker etc) that burned up the battery of the phone plus the device had to be unlocked with an 8 character pin code every time I wanted to use it, not so easy to do in some situations and really bad for my user experience.

      Security also has to be treated as a whole, not just making sure that mobility is 100% secure when the current desktop environment gives employees options to extract, save and distribute sensitive information very easily (using usb sticks, dropbox etc).  There are some very innovative ways to code extra security into apps, for example using GPS location, restricting access or requiring extra security when a device/app is being run from unusual locations is just one small example.  If there is a strong will to break through security there usually is a way but since this is such a hot topic I am sure we will see good and secure solutions pretty soon from various vendors because once this is taken care of then the fun begins along with the business benefits. 

      Author's profile photo Matt Harding
      Matt Harding
      Blog Post Author

      Hi Bjorn,

      Sadly funny about the virus checker and 8 char login (hoping it was defence force or similar related as that is very extreme)...

      Also funny how Enterprise has been originally forced to take shortcuts for Mobility, but now as they get more mature, they are more protected than PC's at work when it comes to USB and Email security threats.  What I've learnt at my current customer is the importance of threat assessments so that you do the right amount of security for the relative threats and that it's not a one size fits all.  And sometimes, someone in the company just has to sign off on the risk as no Utility customer is ever going to want a mobile app where they have to enter 8 digit passwords with numbers and special characters included just to check their current usage or similar!

      And I do foresee good'ish solutions (reminds me of Good technologies)...but will the SAP App Marketplace Apps' still work in these scenarios???  Time will tell.



      Author's profile photo Simon Kemp
      Simon Kemp

      Hi Matt,

      Thanks for sharing this. IMHO I can't help but feel like the whole Security issue is being blown way out of proportion. At some level every system is to some extent vulnerable and a risk assessment needs to be made and the appropriate level of security put in place for any given scenario. We need to get over this perceived hurdle, if we can bank online using a secured connection (SSL) and a username/password then we should be able to access our ERP systems! Honestly the biggest security risks are probably people using easy to guess passwords for the sake of convenience.

      I'm with you, I want to see more SAP customers get started with this, and if the SAP strategy truly is "Mobile first" then I'd like to see the barriers (read licensing) to entry become lower - I think selling more licenses for the technology to mobile enable solutions you have already paid for is a bit rich to be honest, imagine if you bought SAP and were then told you needed to pay more to use the SAPGUI! 😛

      This might ruffle a few feathers I suppose but I really believe that in 5 years time (or less) the majority of computer users will be using "mobile first" user interfaces on mobile devices like tablets/phones etc...


      Author's profile photo Matt Harding
      Matt Harding
      Blog Post Author

      Hi Simon,

      I agree security is being blown out of proportion, but I also suggest that security is incredibly important to get sufficiently right.  eg. I only heard last week that a Tomcat reverse proxy can also help with denial of service attacks; so if you can get your reverse proxy (with a whitelist approach), DMZ and denial of service config in place, then for smaller places; you should just do it.  Bigger places do need to think through things a bit more as say a bank needs to deal with much greater number of connections which makes it more open to attack; and with the way banks are in Australia (earning billions of profits); I think they are pretty prone to attack.  eg. A few banks have dual factor authentication, while the others with just a username/password; and I wonder how connected to back-end systems they really are (is it just pointing to a BW system for example)?

      So I'm still pretty adamant that you need to do a level of threat assessment of your solution and use cases regardless, even to just protect yourself from disgruntled employees who want to anonymously blow out your transaction logs on your SAP system.

      But the point is, that shouldn't take long to do and provided you do a penetration/intrusion testing on the solution before go-live; that should be sufficient to get going.

      And licensing is an issue for many and a difficult one for SAP but this is a dynamic area so I'd stay tuned about the various models as it's a known issue to adoption.

      Thanks for the feedback and feathers need ruffling so keep it up!