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

Choosing Between Public and Private Cloud Infrastructures

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:

  1. What factors should I consider as I try to determine whether to use a third party/public cloud computing infrastructure?
  2. 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:
  1. 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.
  2. Improve time to market by quickly onboarding customers.
  3. Address lack of expertise in building and effectively managing cloud infrastructures.
  • Growth stage companies use public cloud infrastructures to:
  1. Reduce product development costs while enabling collaboration among distributed development teams.
  2. Reduce the cost and time to customer on-boarding.
  3. 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).
  4. 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.

Insight as a Service (Part 3)

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.


Insight as a Service

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).

Continue reading

Defining Insight

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.”

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.