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

Forward

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!