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.
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.
There are corporations that have developed so many different applications, in several cases thousands of them, and mobilizing them in a timely manner 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.
We have broadly organized the custom mobile application ecosystem into six categories depending on whether the companies provide application:
Development environments, e.g., Sencha, Xamarin, Verivo and Appcelerator.
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
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:
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.
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
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.
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.
A few days ago I hosted the meeting of our Internet Advisory Board. Preparing for that meeting led me to jot down my thoughts regarding the sector’s monetization opportunity.
I remain bullish on the transformative potential of the Internet in the enterprise that we view as the channel for achieving scale inexpensively and transforming every industry. Three drivers feed our bullishness:
The US-based Millennials (the most Internet-savvy consumers) are entering their prime buying and influence period.
High-speed mobile access combined with improved smart devices (smartphones, tablets, embeddable devices) further accelerates Internet usage. The mobile device opportunity is having a far greater disruptive impact than anticipated
Low penetration of the Internet channel in most industries. In a recent survey conducted by Booz executives from 350 companies reported that they spend 8.1 percent of their R&D budgets on Internet-related tools.
The Internet offers a great opportunity, but also a great challenge for marketers seeking to engage consumers at a time when publishers and platforms are ceding control to users. We see this impacting two areas of focus for Trident: online advertising and marketing applications and services.
Internet advertising has arrived at an important junction that will fuel the next leg of sustained growth. Over the past 10 years we have seen the sector change dramatically. The first wave of Internet advertising growth was driven by direct-response marketing budgets particularly from industries such as auto, travel, tech, telecom, retail, and financial services.
Several structural and technology improvements particularly to display advertising are attracting additional industries but also causing untapped brand budgets sitting inside leader categories to shift. They include:
Programmatic execution combined with advances in media analytics and optimization.
A shift toward integrated data. Data, as well as tools to leverage this data, are now viewed as key component of this new adtech because they are improving targeting and conversions.
Improvements to messaging capabilities through scaled multi-format reach, (though creative still needs to catch up particularly to RTB).
Improved quality metrics on ads.
Brand-safe advertising environments, because brands realize that it is easier to lose control of their brand on the Internet.
Scalable, cloud-based software platforms coupled with a combination of subscription and usage pricing (not unlike what utilities do for their customers) that enable the delivery of this capability as a service.
Taken together, these structural developments will lead to a rising level of confidence among brand-oriented advertisers that will increasingly view online display (in its various forms) as a more desirable complement to, and replacement for, fragmented mass media channels. Brands are allocating an increasing mix of their ad spend to online video. The budget is coming from TV broadcast and print advertising. We see industries such as CPG starting to aggressively allocate budgets to display advertising. While they spend nearly $200 billion globally offline, such advertisers continue to under-invest online.
We are particularly encouraged by projections calling for the share of agency media budgets spent through programmatic channels to increase from 15-20% today to 40-50% by 2015. Some surveys project that between 2012 and 2017 RTB-based spending in the U.S. will grow at a 56% CAGR. Mobile will be a significant driver of overall RTB growth (IDC expects mobile RTB spend in the US will reach $1B by 2015 and $3B by 2017, representing 21% of the total RTB spending).
The accelerating move of consumers and businesses to Internet, as well as the rise of the subscription economy, namely the move to sell products as services sold on a subscription basis, are causing a re-examination of the marketing applications stack. Customers have more knowledge and control over how, when, and why they engage brands. They increasingly expect a unified experience that is consistent across all of their business interactions. Consumers in particular are increasingly empowered to avoid unwanted or undesired marketing. The line between offline and online continues to disappear, and as it does, the line between product and service is also becoming blurred.
As a result of these trends and the associated data explosion traditional marketing approaches are no longer working causing CMOs to reexamine their established practices and assumptions about advertising, demand generation, retention, and loyalty. In the process of this re-examination they are starting to adopt a new class of applications that power awareness, attention, affinity, action, loyalty and optimization. While the space of these new applications today remains extremely fragmented with hundreds of startups having been funded already, large vendors have started to aggressively build, partner with or acquire the technology enabling them to create a new marketing applications stack. To the traditional infrastructure vendors, like IBM, SAP, and Oracle new cloud-based application vendors like SFDC and Adobe have been added, as well as Internet pureplays such as Google, Facebook, Twitter, Linkedin.
The combination of these factors lead us to three observations:
Engagement applications entering the marketing stack. Business applications are becoming critical tools to engage with customers. Engagement applications enable companies to empower interactions with customers across a variety of channels. We have invested in ThisMoment, Extole and 8thbridge under this thesis.
Advertising and marketing are being re-imagined becoming more of a science than an art as earned media become a bigger part of the paid and owned equation and as more data is collected from each customer interaction, integrated and analyzed. Portfolio companies like Exelate, Turn, Jiwire, Brightroll, and Sojern are leading examples of how analytics changes the game in online advertising and marketing.
Subscriptions to software (SaaS) and services will replace existing manual processes and traditional on-premise applications. All of our portfolio companies in this space deliver SaaS applications or provide their service using subscription billing.
As I prepare
to host our SaaS
advisory board on Wednesday I thought that this is a good opportunity to
analyze the 3Q13 of our relevant portfolio companies, and reflect on the sector
in general. Despite what is typically a
slow quarter for most IT and adtech companies, during 3Q13 our portfolio
companies in both of these areas performed extremely well with 90% meeting plan
and a 3 of them beating it. We are also
seeing strong sales pipelines for 4Q13 making us optimistic that this quarter
will be equally strong, if not stronger.
The public SaaS companies we follow are also starting to report strong
results. For the quarter most of the
growth continued to come from North America.
The foreign markets appear to have bottomed out providing additional
optimism for additional good quarters assuming the companies maintain their
focus and execution level.
enterprise SaaS companies we follow, e.g., Netsuite, Workday, Demandware,
Marketo, ServiceNow, Splunk, Jive, Cornerstone OnDemand, have either started
announcing or are expected to announce strong 3Q13 results, that are at least
in-line with analyst expectations. A big event for the quarter was Veeva’s
extremely successful IPO, which, along with the continued strong performance of
Athena Health, and Realpage, provide proof points that vertically focused SaaS
applications are another growth area for SaaS. The market is also becoming more
positive on the public adtech companies driven primarily by RocketFuel’s strong
IPO and Adap.tv’s acquisition by AOL for a very nice multiple. The market is also taking into consideration
the potential benefits of Facebook’s exchange, starting with the companies that
are already part of it. Valueclick and
Millennial Media remain in the penalty box.
In the case of Millennial the concern is primarily coming from
Facebook’s and Google’s moves around mobile adtech. The market is now waiting for Criteo’s IPO in
the next few days.
was no blockbuster SaaS company acquisition during the quarter, we continued to
see strong M&A activity, particularly of smaller companies offering mobile
applications. In addition to strategic
acquirers, large private equity firms continued to aggressively invest in or acquire
smaller, higher growth SaaS companies.
Some thoughts from the quarterly results and the broader market:
IT budgets remain stagnant regardless of what analysts have
been predicting in the beginning of the year, and for that matter every year
for the past couple of years. While the
U.S. commercial sector was better in Q3 than in Q2 and EMEA
spending appears to have bottomed, during 2013 IT budgets will not grow faster
than GDP, i.e., around 2%.
Businesses increasingly realize that they must aggressively
transition to digital/online and are turning to SaaS applications, including
analytic applications, and cloud-based platforms to achieve this goal. As a result, while IT budgets are stagnant,
budgets for SaaS applications continue to increase significantly. Business leaders view that SaaS solutions provide
them with faster time to market and superior ROI.
Enterprises, including global enterprises, are increasingly
comfortable with SaaS solutions.
On-premise software continues to lose market share to SaaS solutions.
Trident’s SaaS portfolio companies like Host
Analytics and ThisMoment are winning contracts to replace on-premise
deployment is severely behind schedule and their ROI is now being
regularly questioned. Brands using cloud-based adtech platforms are
also increasingly comfortable with longer term, subscription like
contracts. However, we need to start
differentiating between flavors of
subscription. In adtech we are not
yet seeing the guaranteed subscription revenue that software companies
drive. Instead we are seeing minimum
subscription guarantees along with some percent of the marketing spend that
goes through the adtech platform, or the promise to spend up to a specific
amount of money during particular a time period (usually 1-2 years) with a
particular vendor for a product or service.
Public and private investors remain attracted to SaaS
companies (both because of the revenue predictability they offer and because
they take advantage of the cloud’s economics). Investors continue to place a
premium on high revenue growth over profits rewarding companies whose revenue is
growing in excess of 50% YoY. The stock
performance of public SaaS and adtech companies that demonstrate revenue
predictability and offer a cloud-based platform and the valuations offered by
venture investors to private companies raising new rounds provide the best proof
of this trend.
The sales pipelines of our SaaS portfolio companies continue
to grow well, further underlying the broader demand for SaaS solutions. Inside sales groups continue to outperform
the field sales groups and drive down CAC.
Even large enterprises are now more comfortable interacting with inside
sales groups and completing a multi-channel sales process that involves phone
and the web and oftentimes very little or no support from the field
organization. As a result, our portfolio
companies are shifting more resources to inside sales and increasingly use
field sales only for very large opportunities or unique situations. In most cases we have encouraged our SaaS
companies to create hybrid sales groups rather than have distinct and separate
inside and field sales organizations. In
most of our SaaS portfolio companies we now see 3.5-4.5x coverage over the quarterly
bookings objective and 3-4 month sales cycles making plan achievement increasingly
predictable. As a result we continue to
see a strong list of sales candidates coming from on-premise software companies
who feel they can make more money working for SaaS companies.
Enterprises are consistently satisfied with the ROI they
receive from SaaS solutions. This leads
to strong renewals and upsells that contribute "negative" revenue
churn, in other words the amount being upsold to existing customers is higher
than the amount of revenue that is churning.
However, the initial ARR contracted by enterprise customer remains lower
than we would have expected, having a direct impact on CAC.
While we are very happy with the inside sales process, larger
corporations still expect more handholding through post sales services than we
would have liked. Many of these services
are now being offered for free or at a low margin by both public and private
SaaS companies in order to facilitate the sale of a subscription.
final note: The
economy is taking hold in several industries. The SaaS model is quickly migrating to other
industries, e.g., retail, publishing, manufacturing, travel. As a result there will be a need for the
development of a broader software
solution ecosystem that facilitates the functioning of this economy.
Since its founding over 20 years ago, our firm
has been investing in enterprise applications companies. Throughout this
period we have invested in every major application platform: client/server,
e.g., Epicor, multi-tier Web-based, e.g., Webify, and SaaS, e.g., Host
Analytics. These days, 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
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
graphdata (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
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
The second quarter of the
year typically proves to be one of the strongest. This time around not
only we were not
disappointed but we also started seeing some strong upside for the
the year. Both our enterprise SaaS and
adtech platform portfolio companies performed extremely well, and a few
from enterprise and adtech) are seeing strong enough demand that could
them to increase their 2H13 bookings and revenue targets. As public
SaaS companies are starting to
report quarterly results we are starting to see similar strong
some of them, whereas the majority are expected to at least meet analyst
expectations. The North American market fuels this growth,
whereas international markets, particularly Europe, remain a concern.
Also, we are seeing more activity in certain
industries such as retail, parts of manufacturing, and logistics, where
application budgets are holding steady and even increasing. In other
industries we continue to see
budgetary pressures as I had mentioned in last quarter’s commentary.
public enterprise SaaS companies we monitor, e.g., Netsuite, Workday,
Demandware, ServiceNow, Jive, Cornerstone OnDemand, have either started
announcing or are expected to announce strong 2Q13 results, that are at least
in-line with analyst expectations. In
fact Netsuite beat analyst expectations.
The public adtech companies had a rougher time during 2Q13. Tremor Video and Marin Software are two
adtech companies that went public during the quarter and the market didn’t
welcome them with open arms. They started
trading down soon after their IPO.
Similarly, Valueclick and Millennial Media continue to be scrutinized by
public markets. Two other private adtech
companies, Yume and Adap.tv, are expected to go public during this quarter, and
a few more will file to go public before the end of the year. I believe that the companies which have
either already filed to go public, or are planning to file, are of higher
quality than the ones that have already gone public. As a result, I wouldn’t be surprised if their
stocks perform better in the public markets than the current set of public
were two acquisitions worth mentioning: Salesforce’s acquisition of
and Adobe’s acquisition of Neolane. In
addition to the size of these transactions, it is interesting to note
allow both acquirers to strengthen their CMO suites. Another
interesting SaaS transaction was the
acquisition of CompuCom by TH Lee, a buyout firm. In the broader cloud
category I should also
mention IBM’s acquisition of SoftLayer.
Large private equity firms are increasing the pace of their investments
in SaaS and adtech companies, e.g., Insight Venture Partners’ investment
Brightedge. Finally, SAP acquired Hybris which derives a relatively
small percentage of its revenue from a SaaS application even though the
majority comes from on-premise software.
Positive aspects of our SaaS portfolio’s performance:
Strong license revenue growth of 10-30% QoQ
for the online advertising platform companies, and 15-20% of the remaining SaaS
companies. We are seeing an accelerating
trend by brands to enter into yearlong contracts with adtech platform
companies, in the process bypassing their ad agencies and foregoing
campaign-based contracts. I had first
reported this trend during last quarter’s commentary. This type of contracts provides more predictable
revenue ramp to adtech platform companies that the public markets appreciate.
The accelerating adoption of SaaS
applications continues. Our enterprise
SaaS portfolio companies are signing more enterprise customers on a quarterly
basis and they expand their footprint within each client enterprise.
Steady renewal rates (90%+) and improvement
on the churn we had seen in the social application companies.
Sales pipelines growing faster than in the
Large IT vendors continue to move
aggressively to partner with private SaaS companies as they are trying to
incorporate more cloud-based solutions in their portfolio.
Negative aspects of our SaaS portfolio performance:
The negative macro environment outside the US
particularly in Europe, and less so in Asia.
This is having more of an impact to our adtech platform companies.
Mobile SaaS solutions are attracting more
attention but not big dollars yet.
Talent acquisition, particularly for sales
and engineering remains difficult.
Under normal market conditions the second quarter tends to be better
than the first and this year there was no exception. However, 2Q13 gave us more indications that
this can end up being a strong year for our SaaS portfolio if the economy continues
to mend and remains in its current trajectory.
In my last blog I tried to define the concept of insight. In this post I discuss insight generation.
Insights are generated by systematically and exhaustively examining a)
the output of various analytic models (including predictive,
benchmarking, outlier-detection models, etc.) generated from a body of
data, and b) the content and structure of the models themselves. Insight generation is a process that takes place together with model generation, but is separate from the decisioning processduring which the generated models, as well as the insights and their associated action plans are applied on new data.
Insight generation depends on our ability to a) collect, organize and
retain data, b) generate a variety of analytic models from that data,
and c) analyze the generated models themselves. Therefore, in order to
generate insights, we must have the ability to generate models. And in
order to do that we must have data. Insights can be generated from
collected data, data derived from the collected data, as well as the
metadata of the collected data. This means that we need to be thinking
not only about the data collection, management and archiving processes,
but also about how to post-process the collected data; what attributes
to derive, what metadata to collect.
In some cases data is collected by conducting reproducible
experiments or simulations (synthetic data). In other cases there is
only one shot at collecting a particular data set. Regardless, insight
generation is highly dependent on how an environment is "instrumented."
For example, consumer marketers have gone from measuring a few
attributes per consumer, think of the early consumer panels run by
companies such as Nielsen, to measuring thousands of attributes,
including consumer web behavior, and most recently, consumer
interactions in social networks. The "right" instrumentation is not
always immediately obvious, i.e., it is not obvious which of the data
that can be captured needs to be captured.
Oftentimes, it may not even be immediately possible to capture
particular types of data. For example, it took some time between the
advent of the web and our ability to capture browsing activity through
cookies. But obviously, the better the instrumentation the better the
analytic models, and thus the higher the likelihood that insights can be
generated. Knowing how to instrument an environment and ultimately how
to use the instrumentation to measure and gather data can be thought of
as an experiment-design process and frequently requires domain
Insight generation also involves the ability to organize murky data,
which is typically the situation with environments involving big data,
and focus on the data that makes "sense," given a specific context and
state of domain knowledge. Focusing on specific data given a particular
data doesn't mean that the rest of the collected data is unimportant.
It's just that one cannot make sense of it at that point in time.
It is important to not only collect and organize data, but also to
properly archive it, since insight generation may only become possible
when a body of archived data is combined with a set of newly collected
data under a particular context. Or that the combination of archived
with new data may lead to additional insights to those
generated in the past. As the body of domain knowledge increases and
new data is collected it may be possible to extract new insights even
from data collected in the past. Consequently, having inexpensive and
scalable big data infrastructures enables this capability.
Insight generation is serendipitous in nature. For this reason,
insights are more likely to be generated from the examination of several
analytic models that have been created from the same body of data
because each model-creation approach considers different characteristics
of the data to identify relations. We maintain that model analysis,
and therefore insight generation, is facilitated when models can be
expressed declaratively. A good example, of the advocated approach is
used by IBM's Watson system. This system uses ensemble learning to
create many expert analytic models. Each created model provides a
different perspective on a specific topic. Watson ensemble learning
approach utilizes optimization, outlier identification and analysis,
benchmarking, etc. techniques in the process of trying to generate
While we are able to describe data collection and model creation in
quite detailed ways, and have been able to largely automate them, this
is still not the case with insight generation. This is in fact the most
compelling reason for offering insight as a service; because we have
not been able to broadly automate the generation of insights. What we
have characterized as insight today has to be generated manually by the
analysis of each analytic model derived from a body of data, even though
there there is academic research that is starting to point to
approaches for the automatic generation of insights. The analysis of
the derived analytic models will enable us to understand which of the
relations comprising a model are simply correlations supported by
the analyzed data set (but don't constitute insights because they don't
satisfy the other characteristics an insight must possess), and which
are actually meaningful, important and satisfy all the characteristics
we outlined before.
As I mentioned, in most cases today utilizing insights that are
generated manually by experts and offered in the form of a service may
be the only alternative organizations have to fully benefit from the big
data they collect. The best examples are companies like FICO, Exelate,
Opera Solutions, Gaininsight and a few others. However, there are
additional advantages to offering insights as a service:
Certain types of insights, e.g., benchmarking, can only offered as a
service because the provider needs to compare data from a variety of
organizations being benchmarked.
Offering insight as a service could lower the overall cost of
generating and reasoning over insights. This means that even
organizations that can generate insights on their own may ultimately
decide to outsource the insight generation and reasoning processes
because specialized organizations may be able to perform them more
efficiently and cost effectively.
Offering insight as a service enables organizations to benefit from
the expertise the insight generator develops by offering insights to
multiple organizations of the same type. For example, FICO has now
developed tremendous credit insight expertise which no single financial
services organization can replicate.
I wanted to close by making the following point: I have argued that
for an insight to be valid it must have an action associated with it.
This action is applied during a decisioning process. The
characteristics of a particular decisioning process will also need to be
taken into consideration during the insight/action-generation process
because the time (and maybe even other costs) allocated to apply a
particular action during the decisioning process is very important.
Watson's Jeopardy play provided a great illustration of this point, as
the system had a limited amount of time to come up with the correct
response to beat its opponents. Below I provide an initial, rudimentary
illustration of the time it needs to take to action specific actions in
are starting to make progress in understanding the difference between
patterns and correlations derived from a data set and insights. This is
becoming particularly important as we are dealing more frequently with
big data but also because we need to use insights to gain a competitive
advantage. Offering insight-generation manual services provides us with
some short term reprieve but ultimately we need to develop automated
systems because the data is getting bigger and our ability to act on it
is not improving proportionately.
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."
An insight is the identification of cause and effect relations among elements of a data set that leads to the formation of an action plan which results
in an improvement as measured by a set of KPIs. Insights are
discovered by reasoning over the output of analytic models and
techniques. This output can take the form of predictions,
correlations, benchmarks, outlier identifications and optimizations.
The evaluation of a set of established relations to identify an insight, and the creation
of an action plan associated with a particular insight needs to be done
within a particular context and necessitates the use of domain
Most analytic model outputs do not provide insights. There are two
reasons for this. First, the models don't suggest a meaning for each of
their findings. Second, they don't put each finding in an actionable
context (even if the meaning were known). Finding a pattern doesn't
imply that you automatically find meaning and that you understand it.
It just implies that you are finding a correlation among a data set.
Moreover, finding causality alone is not necessary and sufficient for
generating an insight. One needs to be able to derive an action plan
that can successfully and effectively, i.e., with impact, be applied in a
particular context. This requirement implies that even knowing the
meaning of the finding doesn't tell me how to generalize it and use it
for something in the context I am trying to impact. That step requires
knowledge of my environment (business, social, education, etc.),
my strengths and weaknesses, other forces that may enhance or diminish
my efforts, etc.
An insight must be:
Stable. This means that an insight must not vary
depending on the relation-identification algorithm/model being used.
For example, if I use two different samples from the same data set to
create a predictive model employing the same model-creation method, then
the resulting models have to provide the identical result under the
same new data input.
Reproducible. This means regardless of how many
times a feed a particular data set through an insight-generation system,
the same insight will be produced.
Robust. This means that a certain amount of noise
in the input data will not diminish the quality of the insight. This is
particularly important requirement in big data environments.
Insight-generation systems must be able to organize noisy data and
focus on the data that makes "sense," based on a particular context.
Enduring. This means that the insight is valid for an amount of time that is related to the underlying data's "half life."
Because of the above requirements, insight-generation necessitates
the deeper analysis, including the causal analysis, of the underlying
relation-identification models, rather than just the testing of each
model's accuracy, as it is typically done in predictive analytics tasks.
Such causal analysis implies that when trying to generate insights it
is preferable to utilize machine learning techniques that describe
patterns declaratively, e.g., decision trees, rather than black box
approaches, e.g., neural nets and genetic algorithms. As a result of
this requirement, one may need to sacrifice prediction accuracy and
speed for expressiveness. Therefore, one needs to identify the domains
where insight-generation may be more important than predictive accuracy.
Moreover, because the models themselves need to anallyzed, simpler
models may be prefered to more complex ones.
Insight-generation is not a single shot process. Once an insight is
generated and the associated action plan is created, it is important to
apply the plan in the particular context and measure its impact. The
collected data must then be compared to the set of established KPIs in
order to determine whether the particular insight/action-plan pair led
to an improvement. Depending on this analysis, the system must then
decide whether to attempt improving the action plan, create a completely
new plan (assuming that alternatives can be found), or try to create a
brand new insight. This means that from a set of initial input data the
insight-generation system must seek to derive all possible predictions,
based on the set of available models.
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.
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.
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
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.
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.
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
e.g., consumer vs corporation, the number of users, e.g., hundreds for a
specialized corporate application, to millions for a typical successful
application, the application company’s stage, e.g., the SLAs for an
that is entering its initial deployment phase are oftentimes different
SLAs of a fully deployed application, the geographies where the
will need to operate, e.g., data storage and retention regulations in
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
party public infrastructure will enable the company to meet this
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
e.g., consumer, SOHO, or applications targeting specific segments of the
broader SMB market, e.g., Square, LevelUP, Milyoni, can be developed and
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
accommodate them. Moreover, the
scalability and capabilities of these infrastructures are constantly
so keeping up with the applications’ growth is possible. SaaS
as Evernote, or Carbonite that have more stringent SLAs and, in addition
consumer and SMB segments, target the enterprise, run on proprietary
infrastructures because third party infrastructures cannot meet their
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.
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.
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
SaaS companies use public cloud infrastructures to:
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.
time to market by quickly onboarding customers.
lack of expertise in building and effectively managing cloud infrastructures.
companies use public cloud infrastructures to:
Reduce product development costs
while enabling collaboration among distributed development teams.
Reduce the cost and time to customer
Utilize the elastic supply of
computation and storage provided by the public infrastructures in order to
easily grow their customers while meeting SLAs.
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
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
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
needs of the SMB segment and using their own private infrastructure to
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
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
or that can it easily migrate from one public infrastructure to another,
in this way also avoiding vendor lock-in. The problem with hybrid
that you have to keep track of multiple different security platforms and
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
services then it needs to build and deploy its application on its own
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.