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.
Since 1999 we have been investing in companies that develop SaaS applications targeting the mid-upper and global enterprise. Through these investments and the hundreds of other SaaS companies, targeting these and other segments, we have considered during this period, we have started to notice a transition in the way companies utilize cloud computing infrastructures platforms to develop, test and deploy their applications. In the last 5 years SaaS companies, particularly the earlier stage ones, have started to transition from exclusively building and deploying their applications on custom developed infrastructures, to utilizing third-party infrastructures and platforms for these tasks. Third party infrastructures come in two flavors: Infrastructure as a Service (IaaS), e.g., Rackspace, VCE, or Amazon’s AWS, and Platform as a Service (PaaS), e.g., Salesforce’s Heroku, or Microsoft’s Azure. During this period we have seen SaaS companies for which developing and deploying on a public infrastructure was absolutely the right decision, e.g., Dropbox developed and continues to deploy on AWS, and others which had to switch to a private infrastructure after having initially developed their application on a public one.
The decision to employ a custom/private infrastructure for a SaaS application, or, alternatively, the decision to switch from a public to a private infrastructure to develop and deploy such an application are expensive propositions for a SaaS company of any size. Using a private infrastructure means that the SaaS company has full control of its infrastructure but also that a meaningful percentage of its capital is spent for the development, maintenance and upgrading of this private infrastructure. Switching from a public infrastructure to a private one, or even switching among public infrastructures, done without proper planning leads to delays in product release schedules, increased downtime and low customer satisfaction.
SaaS entrepreneurs and management teams are asking two questions regarding the platforms and infrastructures used for their applications so that they can accomplish their development, testing and deployment goals while building profitable companies, maintaining their customers trust and expectations:
- What factors should I consider as I try to determine whether to use a third party/public cloud computing infrastructure?
- When should I move from exclusively using a public cloud computing infrastructure, even in a single-tenant mode, to using a private/custom infrastructure or to using a hybrid approach?
We see entrepreneurs selecting a third party platform to start developing their SaaS applications because they instinctively believe that the associated costs, for both development and initial deployment, will low. They are often right about the startup phase of their business. However, the decision for the long term use of such infrastructures is not as simple as it first appears because several interdependent factors need to be considered. They include:
- The economics associated with the company’s business model. For example, a SaaS application that will be monetized using an advertising or a freemium model has very different economics than one that will be sold and monetized through a direct inside sales model. The paying users of the application’s premium version must subsidize the usage of a very large number of users that utilize the application’s free version. Therefore, the company’s operating model must take into account the costs of running the infrastructure used to develop and deploy such an application. One can then determine if the company can create a profitable model using a third party infrastructure or roll out its own private infrastructure.
- The SLAs the SaaS application will need to meet in order to satisfy its customers. These SLAs can range from uptime to response time, from backup time to failover time, etc. SLAs are themselves a complex factor. They are dictated by the type of target user, e.g., consumer vs corporation, the number of users, e.g., hundreds for a specialized corporate application, to millions for a typical successful consumer application, the application company’s stage, e.g., the SLAs for an application that is entering its initial deployment phase are oftentimes different from the SLAs of a fully deployed application, the geographies where the application will need to operate, e.g., data storage and retention regulations in one geography may be different than in another. Each SLA has an associated cost. For example, if it is necessary for a SaaS application to run on multiple geographies from the time it is initially deployed, the use of a third party public infrastructure will enable the company to meet this requirement at a lower cost than having to build its own data centers. Certain application types, e.g., entertainment applications such as Flixster, general utilities such as Wunderlist or Open Table, etc., that are targeting particular market segments, e.g., consumer, SOHO, or applications targeting specific segments of the broader SMB market, e.g., Square, LevelUP, Milyoni, can be developed and deployed on third party infrastructures and never need to migrate to private ones. This is because the SLAs associated with such applications are more flexible and the third party infrastructures can easily accommodate them. Moreover, the scalability and capabilities of these infrastructures are constantly improving so keeping up with the applications’ growth is possible. SaaS applications such as Evernote, or Carbonite that have more stringent SLAs and, in addition to consumer and SMB segments, target the enterprise, run on proprietary infrastructures because third party infrastructures cannot meet their SLAs at acceptable economics.
- The regulations governing the industry targeted by the application. For example, the data privacy regulations governing applications targeting the health care and financial services industries often necessitate the use of private cloud infrastructures by companies developing application for this industry.
- The available in-house expertise and the importance of having such expertise. The company must determine whether it has the in-house expertise to build and maintain a custom cloud infrastructure to support application development and deployment, particularly as the company grows, whether acquiring such expertise provides it with a competitive advantage, and whether it is willing to continue incurring the costs associated with the building, maintaining and upgrading the required infrastructure and the associated expertise.
- The company’s stage. Early stage companies have different priorities, e.g., time to market, than later stage ones, e.g., sustaining growth at a reasonable cost.
Based on the factors above,
- Early stage SaaS companies use public cloud infrastructures to:
- Accelerate product development by focusing on the business logic and taking advantage of the ecosystem that is typically built around the third party platform to provide faster a more feature-rich application.
- Improve time to market by quickly onboarding customers.
- Address lack of expertise in building and effectively managing cloud infrastructures.
- Growth stage companies use public cloud infrastructures to:
- Reduce product development costs while enabling collaboration among distributed development teams.
- Reduce the cost and time to customer on-boarding.
- Utilize the elastic supply of computation and storage provided by the public infrastructures in order to easily grow their customers while meeting SLAs and regulations (geography-specific and/or industry-specific regulations).
- Achieve their growth goals while controlling capital and operating costs.
SaaS companies start using public cloud infrastructures and remain in such infrastructures if they target consumer and SMB market segments under business models that allow them to make money using such infrastructures, and can satisfy the SLAs of their target segments. Companies start with public cloud infrastructures and completely migrate to custom/private ones when they want to target mid-upper and global enterprises. If they target both the SMB and the large enterprise segments then they can use a hybrid approach remaining on public infrastructures to address the needs of the SMB segment and using their own private infrastructure to address the large enterprise segment, as Workday does which runs its application on both its own infrastructure, as well as in AWS. In all of these cases when a migration from a public to a private cloud infrastructure is contemplated I advise the companies to build their application assuming a multi-cloud strategy. This means that the application can simultaneously utilize several public cloud infrastructures, or that can it easily migrate from one public infrastructure to another, in this way also avoiding vendor lock-in. A multi-cloud strategy allows the company to avoid cloud vendor lock-in, effectively deal with SLAs and regulations (as described above), and better address demand elasticity (again, as described above). The problem with hybrid environments is that you have to keep track of multiple different security platforms and ensure that all aspects of your business can communicate with each other. Finally, if a company develops a SaaS application targeting a regulated industry such as health care or financial services then it needs to build and deploy its application on its own private infrastructure.
Determining the infrastructure and platform on top of which to develop and deploy a SaaS application is not as easy as it may initially appear particularly if the company is thinking long term. The factors I provided above which have been derived from my years of experience in investing in SaaS application companies will hopefully help entrepreneurs and management teams put some structure around this decision.
A few days ago I presented a webinar on Insight as a Service. In the presentation I tried to provide further details on the concept which I first introduced here and later elaborated here. I am including the webinar presentation (click on the slide below) and the notes because they elaborate further on Insight as a Service and provide some examples.
The survey data presented in Pacific Crest’s SaaS workshop pointed to the need for a variety of data analytic services. These services can be offered under the term Insight-as-a-Service. They can range from business benchmarking, e.g., compare one business to its peers’ that are also customers of the same SaaS vendor, to business process improvement recommendations based on a SaaS application’s usage, e.g., reduce the amount spent on search keywords by using the SEM application’s keyword optimization module, to improving business practices by integrating syndicated data with a client’s own data, e.g., reduce the response time to customer service requests by crowdsourcing responses. Today I wanted to explore Insight-as-a-Service as I think it can be the next layer in the cloud stack and can prove the real differentiator between the existing and next-generation SaaS applications (see also here, and Salesforce’s acquisition of Jigsaw).
A little over two years ago I wrote a series of blogs introducing Insight-as-a-Service. My idea on how companies can provide insight as a service started by observing my SaaS portfolio companies. In addition to each customer’s operational data used by their SaaS applications, like all SaaS companies, these companies collect and store application usage data. As a result, they have the capacity to benchmark the performance of their customers and help them improve their corporate and application performance. I had then determined that insight delivered as a service can be applied not only for benchmarking but to other analytic- and data-driven systems. Over the intervening time I came across several companies that started developing products and services that were building upon the idea of insight generation and providing insight as a service. However, the more I thought about insight-as-a-service, the more I came to understand that we didn’t really have a good enough understanding of what constitutes insight. In today’s environment where corporate marketing overhypes everything associated with big data and analytics, the word “insight” is being used very loosely, most of the times in order to indicate any type of data analysis or prediction. For this reason, I felt it was important to attempt defining the concept of insight. Once we define it we can then determine if we can deliver it as a service. During the past several months I have been interacting with colleagues such as Nikos Anerousis of IBM, Bill Mark of SRI, Ashok Srivastava of Verizon and Ben Lorica of O’Reilly in an effort to try to define “insight.”
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.
- 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.
- 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.
- 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.
- 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, Capriza, StarMobile, 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:
- Development environments, e.g., Sencha, Xamarin, StarMobile, Verivo and Appcelerator.
- Testing, e.g., uTest and Appurify.
- Virtualization systems, e.g., PowWow, StarMobile and Capriza.
- Management, e.g., MobileIron, Appfirst and Critercism.
- API management, e.g., Apigee and Mulesoft.
- Security, e.g., Mocana, Cloudmine.
- Development services, e.g., Solstice, Vibes, Kony.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.