When to consider the technology stack in your exit strategy
We spend a lot of time helping private equity investors and tech executives think through exit planning and exit strategy. During those conversations, we are often asked how much a company’s tech stack matters both in the attractiveness towards an acquirer and in the ultimate valuation. While there are numerous anecdotes to support a wide variety of conclusions, we thought that given the significant change we have seen in this landscape the past few years that a more methodical approach was warranted.
Changing Tech Stacks
Back in the not so distant past when almost every business and virtually all customers were running on Microsoft Windows desktop operating systems and on-premises server infrastructure, there was little need to focus on designing software with heterogeneous integration in mind. Traditional APIs (application program interfaces) like Java or C++ classes offer little compatibility to other technology stacks. However, as devices such as Macbooks, tablets, and smartphones using other language and technology stacks have gained widespread popularity, developers were forced to design for cross-compatibility and integration. This resulted in the adoption and deployment of web services APIs (typically based on protocols known as SOAP and REST and data exchange languages such as XML or JSON). The loose binding approach of web services addresses the compatibility issue through the way software information is exchanged. Web services provide applications with the essential data in an agreed upon extensible framework that can be easily used in any tech stack. Furthermore, the loose binding approach of web services allows applications to take advantage of new APIs through simple configuration and without the need to add or rewrite existing code.
With widespread web services APIs in place, today’s acquirers are less likely to require a homogenous programming language, and more likely to acquire applications and infrastructure written in disparate programming languages on heterogeneous stacks. In this new world, applications can rely on web services and other flexible integration techniques to avoid the problems encountered by systems using traditional programmatic APIs. The recent history of the most prolific acquirers and their acquisitions demonstrates this shift.
Microsoft has long been the epitome of a company with a homogeneous technology stack. Microsoft’s infrastructure (Windows, Exchange, Sharepoint, SQL Server) are all built on C++ or .Net using the Windows and .Net programming frameworks. While not everything is in a managed code environment, virtually all Microsoft infrastructure software is built on the Windows APIs and much of the .Net foundation stack.
It is in Microsoft’s Azure Cloud offerings and their Dynamics applications where we are beginning to see some change. While Dynamics and Azure are .Net centric, in both cases Microsoft has broken the mold and began to move beyond a pure .Net framework. The shift has been driven by a need for advanced mobile applications, which must be built on a device’s native stack (e.g. Java for Android, or Objective-C for iOS), and has been enabled by web APIs. For example, let’s look at the recent Yammer acquisition:
Microsoft acquired Yammer in 2012 for $1.2 billion to serve as the enterprise social platform for all of its applications. Yammer is primarily written in Ruby and Java but has since been integrated into the “very .Net” Office 365 and Dynamics. How could this be? Since Yammer is a SaaS offering, any heterogeneity issues that an enterprise CIO might be concerned with when purchasing on-premises products, such as the need to host an application on multiple hardware and software platforms, are non-issues.
While we know that Microsoft still prefers .Net acquisitions, the trend is clear particularly in recent months. Microsoft has made a push to modernize its front-end software, mainly for mobile but also for the desktop (see Figure 1). Under new leadership, and recognizing that Windows will not dominate mobile like it has the desktop and that robust analytics might be suited to platforms other than .Net, Microsoft has recently purchased Sunrise Atelier (calendar), Resource Analytics (analytics), and Acompli (mobile outlook). None of these are .Net based products.
Since acquiring Sun Microsystems in 2010, and with it the mantle of Java stewardship, Oracle has moved to be a “Java First” shop, particularly in enterprise applications. While certain infrastructure software at Oracle such as storage management systems, the database kernel, network management systems, and the Solaris operating system is written in C or C++, the Oracle applications stack is a Java based set of programs and middleware. Thus, it has been Oracle’s preference the past 5-10 years to acquire mainly Java-based products. Unlike Microsoft, however, Oracle has never been as religious about it and has tended to disregard this preference when there was an opportunity that gained them significant market share or provided an avenue to be a thorn in the side of a major competitor.
Looking at Oracle’s last few major acquisitions we find mostly Java-based products. Responsys, Blue Kai, and Datalogix are all built on Java stacks. However, one of Oracle’s most significant acquisitions that bought them a place at the table in the rapidly growing Marketing Automation sector, is Eloqua, a .Net Microsoft stack all of the way through to its SQL Server database. Eloqua runs exclusively in a SaaS configuration, thus hiding many of those details from its customers. A look at the Eloqua developer cookbook indicates examples of connecting to Eloqua using web services with a Java client as well as with clients written in other languages. Like we saw with Microsoft, in a SaaS web services world Oracle shows more flexibility, particularly for a strategic acquisition.
Since its inception, Salesforce has relied very heavily on the Oracle Platform and has built its applications primarily in Java. Early on, to gain confidence from the enterprise, Salesforce published detail specifications of its database and application architectures, emphasizing its use of Oracle’s technology. Accordingly, its acquisition history has been very much slanted towards Java-based platforms, even though it is a pure SaaS company and doesn’t have to worry about some of the issues on-premises products have to address when integrating a heterogeneous stack.
Having said that, Salesforce has kept its preference towards Java for two reasons. First, the company will be able to maximize its use of its talent, because employees will be familiar with tools used regardless of which product line they work on, allowing flexibility and synergies between products. Second, the Apex scripting language that ties all Force.com applications together, is very much based on Java and thus provides a more seamless integration with Java based products. One significant recent exception is ExactTarget, a .Net based marketing automation platform acquired by Salesforce in 2013 for $2.6 billion. This transaction indicates that while Java might be a preference, for the right business case, Salesforce will rely on web services and other integration approaches to harmonize its products.
IBM and SAP
IBM and SAP are both shops that prefer the Java stack. But both companies have relied on inorganic growth for so long that they have methodologies in place that allow them to acquire products built on a variety of platforms. In some cases they might have to factor a “re-platforming” cost into an acquisition, which can mitigate the value and time-to-market advantage of an acquisition candidate, and in other cases they either don’t integrate, loosely integrate, or in web-based products rely on the aforementioned web services for integration.
Some of the recent acquisitions of IBM and SAP include Silverpop, Softlayer, Xtify, Concur, and Hybris. Of these, only Concur is a primarily .Net company, while the others are built on Java stacks.
Of particular interest, last year IBM acquired Cloudant, one of the companies behind the No-SQL database CouchDB. While Cloudant offered enterprise licenses and maintenance contracts, IBM wanted it for its “data as a service” offering which is now integrated with its Softlayer acquisition.
While Cloudant has some Java services surrounding the database, the core engine is written in Erlang – far from the popular Java or .Net stacks. Unlike older databases, Cloudant relies heavily on web services APIs to store, retrieve and query data. As a result, the use of the esoteric Erlang language is no more than an implementation detail to the thousands of Cloudant, now IBM, customers added to their base just in the past few years.
Google, Facebook and Others
In the world of newer, cloud-based companies, with less legacy and almost no on-premises applications software, we find that the stack matters much less. An analysis of Google, Facebook, Twitter, Box, Dropbox, and other emerging web players indicates that the stack doesn’t matter very much. While the tendency at most of these companies is either Java, PHP, Ruby, or Python, as long as the software service supports integrations via some form of web services APIs, the acquirer is able to develop an integration plan and the business case necessary in order to consummate an acquisition. Figure 1 further illustrates how the big players have reached out of their traditional playing field in recent years.
In a rapidly evolving SaaS world that requires agility, time-to-market, seamless integration, and flexibility, the capabilities of a system and a system’s web services APIs will be more important in driving M&A value than the stack.
However, the stack does matter on the edges, and the fact remains that of the large enterprise acquirers, many more have a preference towards Java than to .Net, while some of the newer players have made investments in PHP and Ruby. As the walls are coming down, they have not yet been reduced to rubble, and thus, stack is still a factor that should be assessed when thinking about exit strategy.