The official hub of The Enterprise Mobility Foundation
Want more than just blog posts? Login or Sign up for a free acount and get research, videos, slide decks and more! Join the online social network for Enterprise Mobility.

BYOD’s Impact On Mobile Enterprise Applications

I had an interesting conversation today with someone regarding my thoughts on how HTML5 Is Not (Yet) a Panacea For Mobile Enterprise Applications.  The person asked one question that got me thinking.  Is there any impact on your mobile enterprise application strategy if you choose to allow personally liable devices to be used in the workplace.  It’s actually a great question, because in fact, I see many similarities in this question as how mobile platform support has evolved over the last couple of years.

Let’s take a quick walk down Memory Lane.  If you recall just a few short years ago, mobile devices were overwhelmingly purchased and provisioned by the workplace itself.  Obviously then, BlackBerry was the king of the smartphone hill with Windows Mobile biting at its heels (and Symbian of course outside of North America).  The workplace – specifically the IT department – had it “easy” back then.  They supported (typically) one mobile platform.  And then of course came along Apple and Google to completely blow that approach out of the water with the wildly popular iOS and Android platforms.

People somehow got the crazy idea that they had the right to choose whichever device they wanted and that the IT department was simply going to have to deal with it.  Enter the phase of the consumerization of enterprise mobility.  IT departments pushed back…and then the C level execs got shiny iPhones and Android devices for Christmas or birthdays.  This of course raised the need for organizations to leverage mobile device management solutions from third party vendors that can support various operating systems.  Today, there’s a general consensus that because of the acceptance of the Bring Your Own Device approach, organizations are going to have to support Android, BlackBerry, iOS, webOS (to a certain extent) and Windows Phone.

OK…so what about apps?  Now that there’s a strong adoption of not just smartphones but tablets, organizations are thinking a LOT about the kinds of internal applications they can mobilize.  That shiny ERP system sure looks ripe for mobilizing doesn’t it?  But how do you do it?  Do you buy them off the shelf?  Custom applications?  Mobile Enterprise Application Platforms?  Native or HTML5?  How are they going to get deployed?  Where’s our mobile enterprise app store?  That’s a lot of questions to answer.

But here’s an interesting scenario that could emerge.  Developing applications is not a trivial task.  It can take weeks if not months to develop, test and deploy mobile enterprise applications to your workforce.  Someone in the IT department has a bright idea.  Let’s build an application for the most popular platform in our workplace, and then we’ll build an HTML5 “equivalent” for all the other operating systems.  I’ll argue that this approach basically is saying, we’ll support one platform and for all intents and purposes relegate the others to second class citizens.

Sound familiar?  We’ll support one type of device because that makes our lives easier.

We’ve gone through this exercise before.  Funny how we fail to remember and learn from history.  BYOD taught us that organizations are going to have to embrace and support employee choice.  That means that all platforms are treated equally (taking aside the limitations that may exist in any given platform).  Why would we not take the same approach for the mobile enterprise applications that will be running on those devices?  I’ll argue you’ll have to.  Favoritism in terms of platform support does not work in the long run.  Even if you have just two platforms…say iOS and Android devices…are you going to build ONE application and then webify for the other?  Well, what if your CEO gets a new Christmas or birthday present in the form of a shiny BlackBerry or Windows Phone or webOS device?  You’re not going to have those apps ready for that platform?  You may want to think that one through again.

The point of all this, is that as we wait for HTML5 to become the Panacea of mobile application development, you’re going to want to consider how you can provide the best mobile experience to all your employees, regardless of the platform they may be using at that time….which means that just like you support all mobile operating systems for your mobile device management strategy (you DO don’t you?), you’re going to have to develop and support all mobile operating systems for your mobile application management strategy.

8 Comments

  1. Posted July 6, 2011 at 18:34 | Permalink

    I think most organizations do realize the need to support mobile enterprise applications across multiple platforms. Of course, every organization is different and I can only speak to my experiences but I’ve found that many companies building B2E apps start by mobilizing one simple business process (expense approvals) on one mobile platform (BlackBerry) for a subset of employees (sales managers). If all goes smoothly, that’s when we see an acceleration of the company’s mobility initiative – building more apps on multiple platforms for many different groups of employees.

    So although some organizations may view cross-platform support as a necessity when evaluating and purchasing the tools and technology for building and deploying their business apps, it’s usually a requirement that’s needed after they are comfortable with managing their applications on a single platform.

    Your experiences?

    Thumb up 1 Thumb down 0

    • Posted July 6, 2011 at 20:46 | Permalink

      Great commentary Colin. My primary response would be however that while organizations may look to mobilize ONE task on ONE platform as a test bed, they should definitely have a broader outlook in mind as they think about their multi-app, multi-OS, multi-form factor mobile enterprise application strategy. In my experience, organizations are still NOT completely aware of the need to have a truly multi-(fill in the blank) strategy.

      Thumb up 0 Thumb down 0

      • Posted July 7, 2011 at 08:36 | Permalink

        Great comments (and considerations) from both of you on this. If you take Philippe’s strategic considerations and use Colin’s approach (almost a Proof Of Concept for the greater strategy), you stand the best chances for success in the longer term.
        I would only add to this that the chosen criteria (platform, application function, target audience) be selected to be the most “challenging” from an implementation perspective. By this I mean -

        1) Faces the greatest architectural obstacles within the enterprise (security, networking, integration);
        2) Faces the greatest organizational resistance from various stakeholders within the organization (PKI/Security teams, development groups);
        3) Faces the greatest development resource constraints (lack of platform development skills)

        My rationale is based upon past experiences here. Far too often, the “path of least resistence” is chosen for the first application developed. Simple application with minimal requirements/constraints, so to speak. The result – success. The side-effect – the expectation that ALL future projects across platforms will go as well (and as quickly). Better to discover the pain points sooner rather than later.

        Thumb up 0 Thumb down 0

        • Posted July 7, 2011 at 10:26 | Permalink

          Don,
          I see where you’re gong with this and you make a good point. Your mobile application strategy should be flexible enough to support your most demanding and complex requirements; now and into the future. However, I would still recommend starting simple. You never want to bite off more than you can chew. I’ve seen this happen too many times and its not pretty.

          Thumb up 0 Thumb down 0

  2. Posted July 7, 2011 at 12:05 | Permalink

    Great discussion…and great responses. Legacy enterprise applications impede a companies ability to change. Change in business is constant, pervasive and permanent. It is driven by changes in strategy, products, markets, compliance, regulations, competition, global economic uncertainty, etc. It impacts employees, vendors and customers. Legacy systems were not designed to change and they certainly weren’t made to be mobile. However, mobile is only a fraction of the issue.

    If a company develops a browser based UI that decouples the data, process and technology of the underlying systems without a need to modify, integrate or replace those investments…then which device (mobile, tablet, laptop, desktop, home computer, kiosk at the airport) is available is irrelevant. If mobility is treated as a stand alone requirement, or worse, developed as device specific functionality, the underlying weakness of the legacy applications will continually retard businesses agility.

    The actual transactions of the business (not just expense reports) need to utilize better technology (such as mobile), add additional data and enjoy streamlined processes. You can still take a small bite of the elephant as Colin suggested but tackle the complexity issues Don identified.

    As an example: In 90 minutes Toyota was able to utlize next generation enterprise technology to transform their fulfillment operation (previously constrained by a JD Edwards system)into a browser based transaction that workers accessed on mobile computers with print on demand. The simplicity of the browser only interface required zero training as workers were up and running upon first use. The results were a 292% increase in productivity and accuracy soared from 99.6% to Six Sigma.

    As consumers it is great to play Angry Birds. As employees, vendors and customers we have work to do and we need to do it whereever we are as quickly, accurately and visibly as possible. The first generation of browser enterprise transactions that fully support BYOD are more than sufficient. As Web 3.0 and browsers mature…they will stay a couple steps ahead of what ‘business’ needs.

    Thumb up 2 Thumb down 0

    • Posted July 8, 2011 at 08:03 | Permalink

      Steve – What a great story about Toyota. Thanks for sharing. I’m still not sure I fully agree that building a browser based UI is as easy as you make it sound – especially when the rendering engines don’t all behave identically. Even on the desktop/laptop web design is still a pain in the neck.

      Thumb up 0 Thumb down 0

  3. Posted July 8, 2011 at 19:31 | Permalink

    I think time frames are the major factor here. As Steve points out if the quick ROI is there grab it however you can as fast as you can. Success and quick wins will lead to bigger budgets for mobile projects. The other time frame is to consider is how far we have come in the past 2-4 years. Mobile browser rendering capabilities, mobile network data speeds, HTML 5 progress and 3rd party “data translation” optimising services. Combine these all together with the very near future (4G, dual core devices etc) and HTML 5 is the clear answer to support all devices equally. Client side apps will always have a place but for mobile to grow throughout a business the alignment needs to move from vertical apps to a horizontal platform.
    The process as I recommend it right now is.
    Mobile Device Management first. Get visibility and security under control. (Ground Zero before a mixed consumer fleet can be leveraged)
    Apply quick wins with pre built vertical apps like Salesforce or Mobile Learning solutions.
    The 3rd step is then to put a mobile platform in place to grow grow grow.

    Thumb up 1 Thumb down 0

  4. Posted November 17, 2011 at 11:16 | Permalink

    To facilitate BYOD businesses must give employees easy but secure access to the organization’s applications from various devices (including iPads, iPhones, Android devices and Chromebooks), while minimizing the intervention required by IT staff.

    An ideal solution for such a scenario is Ericom AccessNow, a pure HTML5 RDP client that enables remote users to connect to any RDP host, including Terminal Server (RDS Session Host), physical desktops or VDI virtual desktops – and run their applications and desktops in a browser. AccessNow works natively with Chrome, Safari, Internet Explorer (with Chrome Frame plug-in), Firefox and any other browser with HTML5 and WebSockets support.

    AccessNow also provides an optional Secure Gateway component enabling external users to securely connect to internal resources using AccessNow, without requiring a VPN.

    For more info, and to download a demo, visit:
    http://www.ericom.com/html5_rdp_client.asp?URL_ID=708

    Thumb up 0 Thumb down 1

One Trackback

  1. [...] Sources: (1) (2) [...]

    Thumb up 0 Thumb down 0

Post a Comment

You must be logged in to post a comment.