The Elusive Mobile Enterprise Unicorn

Sherri Douville
Jul 10, 2017 · 4 min read

The purpose of this post is to explain why there are no or very few truly mobile first enterprise B2B unicorns today. (if you know of any mobile enterprise unicorns, please list them below). The problem is that most teams who have tried to build a mobile enterprise product, have assumed that high level, desktop-oriented software could be used. Cross-platform native mobile development to meet enterprise specific performance and security requirements is an enormous challenge. This is something we’ve found both exhilarating and gut-wrenching at Medigram. What are the issues?

Do You Know What’s Under The Hood?

In today’s world, there is no separating performance of software from its hardware and the impact of an application’s operating system in all of this. Many developers tend to default to a set of standard tools whether they apply to a new (for example mobile) use case or not. In one instance, some who write programs in specific languages cannot articulate why they’re using the OS that they are, why they chose the back end in their system, etc.

credit: Zvi Avraham

Colleges Do Not Teach Mobile Computing

I’m not just talking about mobile UI design, I’m talking about writing software that performs with an increasing number of cores like our little handheld supercomputers have. Mainstream languages such as Java which is single threaded and relies on sequential processing, means that it operates stepwise, thereby not taking advantage of all cores at once. This is in contrast to parallel processing in a language like Erlang. Sequential operations in Java will become slower over time as the number of cores in your favorite phones dramatically increase, which they already are at a mind boggling rate. Multiple cores bring more compute capacity in aggregate though due to heat mostly, each core itself actually becomes slower individually. This is why web software of the past will increasingly be challenged and further lower performing as mobile phones continue to rapidly evolve.

  1. Developers most often still think in terms of “desktop first” or even desktop only, even when making apps for mobile phones. This is understandable as we code, submit, and compile on the desktop, even for mobile applications. This makes the idea of “eating one’s dog food” pretty opaque.
  2. Technologies originally suited for websites on desktop use cases contribute to slow loading & slow transitions between screens on mobile. These would include popular scripting languages such as Javascript, Perl, PHP, Python, and Ruby on Rails whether these are native apps or “web apps”. None of these descriptions below state their purpose is for mobile enterprise apps. In our field, healthcare physicians who are highly mobile will vote with their taps, not clicks.

Thinking about a web app for mobile? Don’t do it for enterprise. Technology gaps exist between browser and native rendering engines. Paul Kinlan writes an excellent article about this issue

Why would someone imagine that a web oriented scripting language could be appropriate for a mobile back end? When this occurs, it’s because the team has experience in that language, not because they thought it was the best tool for the job. Ask, why did you select these tools and walk me through the paradigm and your thought process?

credit: ianthro.com

Is Security Baked in or Bolted On?

Then there are security issues: https://www.linkedin.com/pulse/could-slack-work-healthcare-security-considerations-sherri-douville

The Web App Theory

Let’s look at a popular web app combo, HTML5 and JavaScript. These tools were never intended for platform-specific development. HTML5 was created for browsers, so the transition to a mobile environment, where device features are very specific, is irrelevant. Engineers who have developed with HTML and JavaScript will admit that the performance expectation wasn’t met — not because the app had to go out to the Internet and pull information, but because it goes through many software layers in order to deliver, literally.

We’re naturally biased at Medigram since we feel responsible for driving urgent, life and death information and latency is unacceptable. If you just want to look at fun photos or any non urgent information on your mobile phone, then most consumer-grade apps are definitely good enough written in html5, Java, Perl, Python, PHP, Javascript, or Ruby. In fact, we use Javascript for our web app so we’re not “against” any tools, we’re just saying let’s examine what tools are used for what purposes and beware the treacherous (complicated, time consuming) multi platform terrain of mobile enterprise. Is your team really up for it and can you get investor support to execute? Are there any shortcuts in enterprise, not in regulated industries, no there aren’t. Just because someone is familiar with a set of tools doesn’t make those tools the right ones for the job. Define the problem, the requirements, then match the tools.

Sherri Douville

Written by

CEO @Medigram Mobile Intelligence For Healthcare http://www.linkedin.com/in/sdouville/CE

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade