BYOD 2.0 Is Here

Move over, BYOD 1.0! BYOD 2.0 is here.

BYOD 1.0 is over. Organizations have recognized the many shortcomings of existing Enterprise Mobility Management solutions and want more. Organizations want to deploy their applications and data securely to any device that is convenient to the end user. They want to manage their data, not their users’ devices. They do not want to have to acquire Ph.D-level expertise in cryptography and identity management in order to secure their data. They want to avoid wasting money maintaining multiple code bases across all the platforms their applications need to support. They want to decouple their mobility strategy from the whims of consumer mobile device vendors, their app stores, and any other third party dependency that makes no sense for their business.

How the BYOD Story Began

The BYOD 1.0 story started in early 2010, when smartphones and tablets started infiltrating the enterprise IT environment in large numbers. A large crop of mobility startups arose to provide solutions that promised to help IT manage all these new devices flooding their networks.

This first generation of enterprise mobility management solutions focused on asserting control over employee-owned devices to enforce a baseline security profile. Early adopters have recognized the shortcomings of these heavy-handed solutions from Mobile Device Management and Mobile App Management vendors—MDM and MAM, respectively.

In the case of MDM, these shortcomings include requiring a user to cede control of their device to IT. This gives IT managers the ability to enforce device-level policies to reduce mobility risk, but at the expense of end user privacy. As a result, MDM-based BYOD programs face significant hurdles to end user adoption.

MAM vendors provide a finer-grained solution that rightly focuses security and management at the application level. However, these solutions require organizations either to rebuild their apps with a secure wrapper or re-engineer the apps with a low-level SDK that inserts management hooks directly into the app. Either way, organizations must incur a significant additional cost before receiving any value from a MAM solution.

Organizations feeling the pain from BYOD 1.0

Organizations are tired of these BYOD v1.0 solutions because they tend to create as many problems as they solve. One contrarian organization has even organized a session at an upcoming industry conference called "You Can Say No to BYOD." Clearly, there must be a better way to solve these problems, short of throwing the baby out with the bath water.

BYOD 1.0 was about managing end user devices. Managing devices required adding the infrastructure to your IT environment to make this possible. Typically, this resulted in slightly more security, accompanied by higher operating costs and technical complexity. BYOD 2.0 is about stripping away technical complexity where possible, inefficient processes, and wasteful spending. BYOD 2.0 focuses on what is most important to organizations: mobilizing their data.

BYOD 2.0 is about stripping away technical complexity where possible, inefficient processes, and wasteful spending. BYOD 2.0 focuses on what is most important to organizations: mobilizing their data.”

BYOD 1.0 – Multi-platform development is wasteful

Application development for mobile has evolved in a way that results in redundant, expensive, and wasteful duplication of efforts. For so-called native development, engineers must implement the same application for each platform they need to support. This duplication results in the maintenance of multiple distinct code bases – one for each supported mobile platform – each solving the same problems. In addition, the steady stream of updates from the native OS vendors on these devices imposes frequent and immediate patching requirements for apps, lest they stop working. This model scales poorly.

Hybrid applications improve on this model somewhat by using cross-platform HTML5, JavaScript and CSS to create a single code base that can work across platforms. Unfortunately, these assets must then be packaged using a native packager, distributed through the same consumer app stores, and updated whenever the underlying OS introduces a new incompatibility. This model also scales poorly.

BYOD 2.0 – Mobilize your data to any device securely and easily

It would be better to be able to deploy pure HTML5 apps into a runtime environment that provides the management and security capabilities missing from hybrid and native apps and consumer web browsers. If the runtime provided an API bridge to native OS and device capabilities, organizations could reap the benefits of both web and native development without the drawbacks of either.

This secure, managed runtime environment would insulate organizations from the rapid evolution of the underlying devices. As long as the runtime supports the device, developers could confidently deploy their application to it with minimal additional testing.

Using a managed runtime to deploy pure HTML5 apps is how you can future-proof your enterprise mobility strategy. Imagine being able to eliminate the costs associated with multiple code base development, native packaging for hybrid apps, and deploying your business apps through public, consumer application stores. Imagine delivering your sensitive data to any device using a platform that is secure by design, giving you end-to-end data security and fine-grained access control for your data. Imagine being able to deliver a superior user experience on any device with a single code base. It’s time to stop dreaming; BYOD 2.0 is here and ready to deliver.

Learn more about how Sencha can help with your journey to BYOD 2.0.

Written by

Nicholas Harlow is the Director of Product Management for Sencha Web Application Manager. Prior to his role at Sencha, he held engineering and product management roles at IBM and helped build innovative software for several other organizations.


  1. Managed Services Dallas says

    Another very strong and powerful post. I’ve been reading through some of your previous posts and finally decided to drop a comment on this one. I signed up for your newsletter, so please keep up the informative posts!

  2. cblin says

    You say that BYOD 1.0 requires “to rebuild their apps with a secure wrapper or re-engineer the apps with a low-level SDK”

    I thought that Sencha space also requires you to rebuild the apps (with HTML5 and the JS API provided), no ?

    Otherwise, I agree that your solution has the benefit to install only one app on the devices so that you are not blocked by (stupid) app stores or (complicated) deployment processes :)

  3. Ingo Hefti says

    > @cblin: I thought that Sencha space also requires you to rebuild
    > the apps (with HTML5 and the JS API provided), no ?

    This is an interesting question. As far as I understand Sencha Space it seems to be a container solution. Your web-app will run within this encrypted container. Data transmission or storage from within the Space app will be encrypted too (which sounds very good). When looking at the sample apps in the Sencha Space Mgmt Console you will find there apps (beside the ones made with Sencha Touch) like Dropbox, Evernote, etc. So apparently they are able to run within the Space container too. Would be interesting to get a word from Sencha as how this was made possible? Thanks.

  4. Abe Elias says

    @cblin Christophe, Space was built to be Framework agnostic. Not only can you build apps with alternative tools, but you can deploy existing assets (Web 1.0 intranets, portals, etc) in Space. Basically, any web tech you feel comfortable accessing via a tablet or phone will work great.

    What you get with Space beyond the management of security settings (PINs, access restrictions, etc) is a secure environment. All data at rest is encrypted. All data in transit can be secured (certificate pinning, etc). Any access to corporate data (behind firewalls/vpns) is virtualized and split-tunneled. All data inside of Space stays inside of Space – key for any DLP policy.

    Rather than including a Native SDK inside a hybrid app to provide similar features, you get the secure environment out of the box.

    In addition to content isolation and the entropic data-at-rest encryption, we provide additional API’s that make it easier to build large scale mobile apps – secure, almost infinitely sized, datastores, secure camera access, network status and data caches, profiles, etc, etc.

    Given the current allergic reactions we have when asked to MDM our personal devices, we need a better way to enable businesses to be more agile and productive. Early feedback confirms Space disrupts the status quo – focusing us back to enabling and extending business value to our end users on every device. We hope you like it.

    Thanks again for all your support (especially back when we were just getting started). It means a lot to many of us here. Feel free to PM me on the forums if you have any more questions or leave an addition comment here.

  5. Abe Elias says

    @Ingo Feel free to post any questions on the forums regarding specific implementation details you are interested in learning more about. I’ll do my best to give an answer.

    Thanks for offering to help on the localization front too!

  6. cblin says

    Thanks Abe for the answer.

    I did not think it was possible to run apps not developped specifically for space but this was a mistake. I think this product can really make a difference then because big companies really have these problems !

  7. Managed Services says

    Hi there! I know this is kind of off topic but I was wondering if you knew where I could get a captcha plugin for my comment form? I’m using the same blog platform as yours and I’m having difficulty finding one? Thanks a lot!

  8. interfaSys says

    The biggest drawback afaics is that it’s yet another container to manage and to try to get to communicate safely with other containers, containing native apps such as email.

    Space apps can’t all live in isolation, they will sometimes need to collect data from emails and to provide data for emails to send to clients, etc.

  9. Dragos says

    This is exactly Java meant to be, unfortunately the commercial war disabled Java as a potential Run everywhere language.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>