Mobilizing Enterprise Applications

Because mobility is starting to impact so many parts of the enterprise for some time now we have been considering how enterprises should be thinking with regards to mobile applications for their customers, employees and partners and have been formulating relevant investment theses.  Based on input we have received from several senior IT and business unit executives we tried to determine when to use mobile-first as an application development strategy and when to focus on a mobile-only strategy.  Through these executive interactions we have also come to realize that, the mobilization of existing applications is a high corporate priority because many of these applications automate proprietary logic about a specific business process that allow an enterprise to differentiate itself from its competitors.  As such, the majority of these applications are bespoke, having either been developed internally or under the specification of the enterprise. For this reason we have focused our initial efforts on understanding the growing startup ecosystem that provide solutions to address the mobilization of existing applications.  (At the end of the post I provide our thinking of this ecosystem). In this post I want to focus on third-party mobile applications which are starting to play an important role in the enterprise.

Enterprises must pay attention to 3rd party mobile applications for two reasons.  First, in order to determine which of the 3rd party desktop, including browser-based, applications they have previously adopted will need to be mobilized.  Second, in order to consider such applications as viable alternatives to internally developed applications whose mobilization is proving unfeasible.

With regards to the horizontal and vertical desktop applications they have already licensed, enterprises face an interesting dilemma.  In some cases they may be able to license an adopted application’s mobile version.  Because enterprises are increasing the use of mobile devices, many vendors have already developed, or are developing, mobile extensions to their flagship products, e.g., Salesforce, SAP, Microstrategy.  In many instances this is the preferred approach because the enterprise is already familiar with the application vendor, has the appropriate license agreements in place, and the relevant data and application integration (and configuration) tasks have already been performed.  However, because mobile application development talent is in short supply, many of these mobile application extensions tend to have several issues such as incompatible and even clunky User Experience (UX), security flaws, web-only implementation while a native application would have been a better fit, and poor functionality compared to their desktop counterparts.   In many cases the software vendor is not able to incorporate in the mobile app key pieces of functionality that the enterprise had previously configured for the desktop app.  For these reasons alone, corporations may want to consider licensing a mobile-only enterprise application from one of the new vendors that are quickly emerging to fill the void (for a partial list of such vendors see here).  For example, RoamBI provides a mobile-only application for business intelligence that competes with Microstrategy’s.

Corporations must consider mobile-only third-party applications for four additional reasons.

  1. In order to rapidly automate a mobile-centric business process that hasn’t been previously automated. Even if the corporation has an application development group, depending on the group’s priorities and talent, it may be easier to adopt the third-party application instead of developing it internally.  Applications like Dudamobile’s that is used for automatic creation of mobile websites and Digby for e-commerce provide good examples for this case.
  2. In order to leverage other third-party software through APIs.  Mobile payment applications provide a good example of this.  Several companies are tackling this space because it is difficult for banks and other organizations to develop their own solutions.  Mobile payments have been growing rapidly, e.g., during 2013 Starbucks drove $1B through mobile payments, and for many enterprises they are starting to represent one of the most important monetization channels.
  3. Allowing enterprises to cost-effectively mobilize an internally developed application.  Cost is measured along a variety of dimensions:
    • Cost to hire the appropriate talent (as many companies are quickly finding out a strong internal application development organization doesn’t automatically imply that it will have strong mobile application development skills; see Yahoo’s recent mobile talent acquisitions in this area).
    • Cost to create the right User Experience (UX).  UX is one of the most important factors to a mobile application’s success.  For example a customer-facing application has different UX requirements than an employee facing one, as banks and insurance companies are coming to realize through the adoption, or lack of, of their mobile banking applications.  This talent can also often be difficult to find.
    • Cost to develop, test, deploy and maintain each application, even if the talent is available.  As in all application areas, oftentimes it is more than adequate to provide 80% of the necessary functionality quickly rather than wait for a long time to provide more than this level of functionality.
    • Cost of being late to market because of the previous 3 issues.
  4. Each corporation has developed many different applications, in several cases thousands of them. Mobilizing them in a timely manner often becomes impossible.  As a result adopting a third party application represents the fastest path to mobilization. Alternatively they can try virtualizing their desktop applications and in this way make them available through a mobile browser.  Companies like PowWow, CaprizaStarMobile, Citrix, included in the ecosystem at the end of this post provide solutions in this space).

While mobile consumer applications continue to dominate investment and M&A discussions these days, mobile enterprise applications present, internally developed or third-party, present an interesting set of issues that we consider as we determine in which parts of these ecosystems to continue investing.


I have broadly organized the custom mobile application ecosystem into six categories depending on whether the companies provide application:

  1. Development environments, e.g., Sencha, Xamarin, StarMobile, Verivo and Appcelerator.
  2. Testing, e.g., uTest and Appurify.
  3. Virtualization systems, e.g., PowWow, StarMobile and Capriza.
  4. Management, e.g., MobileIron, Appfirst and Critercism.
  5. API management, e.g., Apigee and Mulesoft.
  6. Security, e.g., Mocana, Cloudmine.
  7. Development services, e.g., Solstice, Vibes, Kony.

Mobile-first vs Mobile-Only: Additional Thoughts on Mobile Enterprise Applications

In a previous post I discussed how the adoption of mobile devices by customers, employees and partners, as well as the desire of these constituencies for a mobile-like experience even in their desktop devices, is leading to the emergence of mobile as the next enterprise software platform and causing enterprises to accelerate their mobile application strategies.  As a result, CEOs and even corporate board are making mobile applications a priority.  For the most part thus far these strategies involve mobilizing existing applications and embracing a mobile-first approach for the new applications they are licensing or developing internally.  But internally developed enterprise applications, legacy and new, present corporations with an interesting and complex challenge during this period when IT investments remain constrained causing corporations to ask whether they should adopt a mobile-first or a mobile-only approach.

Customers, employees and partners are expecting mobile enterprise applications that match their mobile consumer experiences.  Moreover, as the portion of the enterprise workforce that is becoming mobile is increasing, the applications used must match the employee work norms.  As IT departments are quickly finding out, adopting a mobile-first strategy, particularly for their internally developed applications, can be particularly tricky and expensive because in the process they need to:

  1. Determine whether and how to divide the application’s functionality between the mobile and desktop versions.  For new applications this is an easier task than for legacy applications that will need to be mobilized.
  2. Upgrade their legacy desktop and server-side applications along with their application management infrastructure.  Before developing and deploying a mobile application that tightly integrates and interacts with one or more legacy applications, the enterprise may need to first upgrade these legacy applications.  Such upgrades can be particularly costly as they may also involve upgrading underlying third-party infrastructure software and hardware.
  3. Provide a user experience that matches expectations that are being driven by the consumer internet.  This means that the developer must determine whether to re-create a mobile version of a multi-function enterprise application, or to break the original application into several single-function ones.  In addition, the user interface of the resulting application(s) must match the user expectations, which are now very high.  With older applications it may simply not be possible to create an acceptable, modern mobile user experience.
  4. Develop and manage APIs that allow a legacy application to interact with mobile front-ends and other mobile applications.  In many instances one may only be able to mobile front-end to a legacy application, typically using HTML5.  In other cases, it may be possible to develop a full-blown mobile application that incorporates a portion of the legacy application’s functionality.  These alternatives mean that it may be necessary to expose and manage different sets of APIs for each application.
  5. Address the multitude of security issues associated with mobile devices and the operating systems they use.  In many instances, IT organizations don’t yet trust the security provided by third-party mobile applications.  Forrester Research reports that more than half of the enterprises in North America and Europe are implementing mobile application strategies so that they don’t find themselves with hundreds of security leaks because employees bring their own devices.
  6. Deploy a mobile application management infrastructure.  In most cases, the existing application management infrastructures are inadequate for managing mobile applications as well.

For these reasons, IT organizations are considering mobile-only versions of applications as a means to better respond to customer, employee and partner needs for mobile applications while better capitalizing on their application development budgets.