Improving Corporate Planning through Insight Generation

I want to take a quick breather from writing about corporate innovation and return to another topic of this blog: big data and insight as a service. Host Analytics, one of my portfolio companies, recently completed a $25M financing round. Host Analytics offers a cloud-based Enterprise Performance Management (EPM) Suite that streamlines a corporation’s planning, close, consolidation and reporting processes. But it is what they are enabling for the enterprise that is important to write about. Host Analytics has moved from being an EPM company, to being an insight generation company.

Continue reading

IBM-Apple Deal: Mobile Enterprise Applications

On July 15 IBM and Apple announced an exclusive partnership.  There are several components to this partnership that have been addressed elsewhere (here and here) but of most interest was the commitment to develop 100 industry-specific mobile analytic applications for the enterprise.  As I had written, the broad adoption of smartphones and tablets by employees, customers and partners, combined with a BYOD strategy, is driving corporations to rethink their enterprise application strategies.  They are starting to mobilize existing applications and embrace a mobile-first approach for the new applications they are licensing or developing internally.  Analytics-based insight-generation applications represent a major category of these new applications. Recognizing this trend, I and many other venture investors, have been aggressively funding startups that develop mobile enterprise applications.

Continue reading

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.

Mobile-First: The Future of Enterprise Applications

While the adoption of SaaS applications is increasing, the broad consumer adoption of smartphones and tablets, as well as of other connected specialized devices that are part of the Internet of Things, is driving corporations to accelerate their mobile enterprise application strategies.  As a result, enterprises are starting to mobilize existing applications and embrace a mobile-first approach for the new applications they are licensing or developing internally.  This approach is leading to the emergence of mobile as the application platform.

Previous enterprise application platforms and their associated architectures were created in order to enable the development of applications that automate complex business processes.  The typical enterprise application (internally developed or third-party) tends to have a large footprint, complicated user interface reflecting its complex functionality, long release, deployment and update cycles, and expensive maintenance.  SaaS applications have improved on several of these issues, e.g., release, deployment and update cycles have shrunk and maintenance costs have decreased.  Based on the examples we’ve seen from the consumer world, mobile applications have completely different characteristics.  They provide simple and user-centric functionality, typically automating one task, e.g., making a restaurant reservation, have clean look and feel, small footprint, monetize through new and equally simple business models, and interface with other applications and data through well-defined APIs.  Because of their characteristics, security and privacy become more manageable tasks.

Mobile consumer applications are starting to influence how mobile enterprise applications are designed, implemented, deployed and used, regardless of whether their intended user is the corporation’s customer, its employee, or its partner.  However, mobile enterprise applications have not yet achieved (and here) the range of functionality, sophistication and refinement of consumer applications.  They tend to be straight re-implementations of their desktop counterparts.  Fortunately enterprise application developers are starting to re-think how mobile software can best automate business processes while adopting the norms established by mobile consumer applications.  In the process they need to make the following important decisions:

  1. Select the right business process to mobilize.  In these early days of mobile enterprise applications we see companies making the mistake of mobilizing widely used desktop applications. Rather than starting from the application level, it is important to start from the process level and identify the processes that are best suited for a mobile automation.  I have identified three types of processes that are good candidates for mobile implementations: a) those involving mobile employees, customers or partners, e.g., appointment scheduling for field technicians, b) those which take unique advantage of the sensors, e.g., GPS, camera, found on mobile devices, e.g., route optimization for delivery service drivers, insurance claim submission, and c) those that have been considered too niche for inclusion in a large enterprise application (there is an app for that) and can be implemented easily using the small-team development model that has emerged in mobile consumer applications, e.g., collaborative task management.
  2. Determine the type of application to build (native or web-based).  The debate on whether to develop a mobile application that runs native on the device, such as Walgreens’, or is web-based, i.e., using an HTLM5 UI and a cloud-based back end, such as the one developed by the Financial Times, will continue to rage for a while.  Developers opt for a native application when a) response speed is important, for example Facebook changed from a web-based to a native mobile application in order to improve response time, b) the desired user experience is not adequately supported by HTML5, for example Walgreens’ application as well others that have been recently been released, c) the application is expected to frequently operate in environments with infrequent or no connectivity, or low bandwidth, e.g., while on a commercial flight.  Some native applications are not 100% self-contained on the device but may also need to use the cloud particularly in order to access data or invoke other applications in order to accomplish a task, such as United’s mobile application which accesses a variety of databases with flight and customer data.  There are also very good reasons to develop a web-based mobile application including when a) a mobile application is being quickly prototyped, b) it is not clear which implementation type will best serve the application’s users, c) the application needs to run on a variety of mobile operating systems beyond the major two (iOS, and Android), d) trying to mobilize an existing third-party or proprietary enterprise application (on-premise or cloud-based) by creating a wrapper around it, e) response time and a specific user experience are not issues, and f) monetizing the mobile application through search advertising.
  3. Decide on a business model to monetize the application.  Over the past 2-3 years third-party mobile consumer application companies have been experimenting with a variety of business models: advertising-driven, subscription, freemium, mcommerce.  Third-party mobile enterprise application providers will undoubtedly have to go through a similar experimentation phase for the applications they introduce to the market.  Deciding on the business models that will be tested can also dictate how the mobile enterprise application will be designed and implemented, i.e., not only how the business process will be decomposed but also whether each resulting application will be native, web-based or hybrid.  For, example, as it was mentioned above, if monetization will be through search advertising, then a web-based version of the application is necessary.
  4. Provide the right user experience.  Enterprise applications have typically been built from the bottom up, their developers paying most attention to the business logic and the database structure.  With a small number of exceptions over the past few years, user interface and overall user experience have been afterthoughts.  Mobile consumer applications have demonstrated convincingly that user experience is as important, if not more important, as functionality.  Mobile enterprise applications must establish the same balance with user experience becoming as important as functionality.  Moreover, user experience does not only imply a user interface that engages the user, but also a consistent experience across all mobile devices on which the application will be used (regardless of screen size, operating system, etc.).  This is an important consideration since the application’s users are likely using multiple mobile devices in the course of their daily work activities, in addition to their desktop computers (an excellent example is the approach that Google took with the Chrome browser).  In order to provide the right user experience while mobilizing an enterprise process, it may be necessary to be implemented over more than one application. For example, the process of field workforce management may be broken down into three mobile applications: personnel scheduling, form-filling for data collection, and work-order completion.  In some cases the mobile applications developed to automate a particular business process may need to be organized into a larger composite application where the output of one component application becomes the input to another.  For example, the shopping list application developed by a grocery store chain may be integrated with a third-party in-store navigation application to provide a better user experience.
  5. Take advantage of ecosystems.  Ecosystems that were created through business development partnerships have always been important for enterprise applications.  Companies like SAP, Oracle, Salesforce, Workday, to name a few, have developed platforms on top of which their partners wrote additional enterprise applications.  Today in mobile applications the platform is not simply an extension of a particular application but is the operating system.  During these early days of mobile enterprise applications we are witnessing the creation of ad hoc application ecosystems, e.g., health care applications, and data ecosystems, e.g., quantified self data that can be used by mobile health care applications, and business graph data (enterprise CRM and HR data combined with location data, as well as data from LinkedIn, Twitter, Facebook and other social networks and organized into a graph structure that can be searched and analyzed) that can be used in variety of mobile CRM, HR and SCM applications.
  6. Developing the right APIs.  Application Programming Interfaces (APIs) have always been important for application integration.  They have become even more important for mobile applications as they enable them to interface with distributed heterogeneous data sources, e.g., database, activity streams, etc., as well as with other mobile, cloud-based, or on-premise applications, and offer services such as push notifications, identity management and geolocation.  Writing a robust and well-behaved set of APIs for every mobile enterprise application and documenting them appropriately have become prerequisites.
  7. Make the business application discoverable.  Apple’s and Google’s app stores have demonstrated that it is possible to create millions of mobile applications.  I expect that as enterprise mobility moves from experimentation to mainstream we will see a similar explosion for mobile enterprise applications.  Identifying one or more applications to automate a particular business process, an enterprise user may need to search the mobile device, the corporate cloud/marketplace, or public application marketplaces.  As consumers have already determined, just finding the right applications in app stores is hard enough.  Application search will need to be augmented with a detailed and robust application categorization scheme that enables tasks to be matched to applications, as well as the ability to monitor application usage patterns (users tend to gravitate to a few specific applications that enable them to achieve a lot with little in-depth understanding of an application’s internals).

After extensive experimentation over the past 8+ years (with the advent of the smartphone), we remain in the very early stages of enterprise mobility.  Mobile consumer applications have taught, and continue to teach, enterprise application developers many lessons about design, implementation, distribution and appropriate business models.  As the enterprise’s move to mobility is accelerating we will see the emergence of new third-party application leaders since, at least to date, the incumbent enterprise application providers remain too attached to the design and monetization models they established 20+ years ago.  In the process, in Apple, Amazon, Google, we are already seeing a new set of mobile infrastructure leaders emerge that are seriously challenging the dominance of traditional enterprise infrastructure providers such as IBM, Oracle and Microsoft.  These market conditions make this an excellent time to invest in companies that develop mobile-first enterprise applications.  As we did during previous application platform shifts, Trident is aggressively investing in companies that will become tomorrow’s enterprise application leaders by utilizing the mobile platform.