Let’s start from the beginning — what is an application?
An application is, simply, a computer program that a user interacts with to accomplish some task or perform an activity. There are a wide range of apps, both enterprise and consumer. We’re going to focus on enterprise applications.
Enterprise applications, to over simplify, provide opinionated frameworks for how a specific business function or business process should be done, and enable you to do (some portion of) those tasks. In order to accomplish this, these applications provide a data model, which again provides an opinionated view into how that function or process should be viewed and structured.
Let’s take Salesforce CRM as an example (we’ll use this example throughout, for reasons that will later become clear; this will also serve as an explainer and refutation to the large portion of the world that loves to complain about how terrible Salesforce is as a product).
At its core, Salesforce provides an application that allows Sales and GTM teams a way to track the way that you sell your product to customers, and the associated analytics and metrics to track it. It controls the core customer data for a business — the customers, contract values, interactions with that customer, plus the state of all interactions with future customers across the stages of the sales pipeline.
But from a technical perspective, what is Salesforce? For the purposes of this discussion, let’s assume that Salesforce has three parts — the UX that end users interact with (the app itself), middleware that connects that application to the back ends, or databases, where the data itself is stored.
The user of the Salesforce app, of course, sees none of this — they just interact with the interfaces that Salesforce provides. But it’s important to understand this, because it’s a useful framework for decomposing the value of an application, and viewing it in the broader context of apps, platforms, and ecosystems.
From application to platform
Investors at all stages discuss the concept of platform — they want to invest not in tools, nor in products, but in companies that have the potential to become platforms. There are many definitions of platform, depending who you ask — I propose that we’ll use the following: a platform is an application that provides a set of interfaces upon which other applications can be built. Essentially, it allows for extension and customization on top of the data models that are defined in the core platform application.
Returning to Salesforce as an illustrative example, their platform story manifests in many places. We’ll focus on three — Force.com, AppExchange, Lightning Apps.
Force.com
Force.com was Salesforce’s move into the platform as a service business, which allowed customers to build custom applications that are deployed to and hosted on Force.com, sitting on top of the Salesforce data model. Whereas the Salesforce native app provides a specific set defined (though semi customizable) views, pages, and visualizations, Force.com providers developers an IDE to build custom apps using custom objects, fields, and workflows, written primarily in javascript, C++, and visualforce (created by Salesforce) .
This enables developers (including a wide range of 3rd party Salesforce consultants) to create custom applications that are tailored to the specific processes and workflows that exist in their organization. Remember that enterprise software at the end of the day is an opinionated view of how a process or function works — and while there may be overlap, no two businesses are the same. This is especially true when you start to look across industries, company sizes, geographical presence, any many other segmentations. Even within an organization, different business units may look and act differently. Force.com provides customers the ability to take the core Salesforce application experience and customize it for their own needs.
AppExchange
The Salesforce AppExchange is a marketplace of applications built by 3rd parties to extend and expand the functionality of Salesforce across industries, geographies, and functional areas. Whereas Force.com allows developers to build and deploy apps against their own Salesforce instances and data, the AppExchange allows for external developers to create their own apps, to be published into the marketplace for consumption by all Salesforce customers.
Think of it as a way for companies and software developers to leverage the power of the Salesforce platform and its install base to distribute apps they create, that fill specific needs that out of the box Salesforce does not.
Lightning Apps
Whereas Force.com would be considered a developer product, Salesforce released Lightning Apps as a part of their rebrand to Lightning around 2015, and has been adding new features (and changing naming conventions) over time. At the core, however, Lightning provides both low- and no-code development experiences for non-professional engineers to create, deploy, and manage both mobile and desktop applications.
These apps serve a number of purposes — but largely serve to expand who can customize and build Salesforce apps. Business users outnumber developers by a huge margin at most organizations, and by opening up the aperture of who can participate in the development process, you rapidly increase the number of people that can participate in and benefit from the Salesforce ecosystem at a company.
So, why does Salesforce care about this? or, systems of engagement versus systems of interaction
Salesforce has long understood that their core value and defensibility is that businesses are inherently customer centric, and the most valuable data at a company is the data related to how they sell to and serve their end customers. Every sales leader uses a CRM, and many use Salesforce (though, surprisingly, only 20% of the market uses Salesforce CRM).
This has led Salesforce to be a system of record for managing data on arguably a company’s most important asset (ask your board and shareholders… no sales — no company!). Data has gravity, and this system of record both commands immense value on its own, but also creates influence on all other systems within an organization. Other systems need to play well with Salesforce, because if they don’t, they’re unlikely to be adopted. This makes Salesforce the System of Record. They have leveraged this to build a number of other large businesses in addition to sales — namely marketing cloud, service cloud, commerce cloud.
If your marketing system has to understand who your top prospects are, and those live in Salesforce, your marketing system must be able to read from (and probably write to) Salesforce. Imagine trying to bring a lead scoring tool into your organization, and telling your CRO you need to switch Salesforce for another CRM, because your lead scoring engine won’t work with Salesforce. Not going to happen. Please don’t try this.
If you take as a fact that we’ve established Salesforce as the System of Record and center of gravity for how a company operates its go to market organization, we can then move on to the question of how people interact with that data. In some cases it’s simple - you have a Salesforce administrator who creates the right views, fields, and reports that correspond with how your organization runs, and everyone logs onto Salesforce.com to view it.
But in many cases, you have many different users, who have varied needs, across both B2B and B2C. The day to day of inside sales, field sales, customer success, marketing, are all very different. Management versus individual contributors also have vastly different usage patterns. Some might be at a desktop, some might be on an iPad. Some might be on the phone all day.
Each of these users engages with the Salesforce platform in a different way. Some “users” are developers that only ever engage with that platform via APIs that are exposed. Some users aren’t even really people — they might be other software systems, provided by Salesforce or external to it entirely.
The various interfaces through which these parties interact with Salesforce are the Systems of Engagement. These are the methods by which you interact with, and get value from the data that you have stored and structured (storing data for the sake of data generally benefits no one, except maybe your cloud provider). It is also the way in which subsequent data is entered into the system, creating defensibility for the platform. These interfaces might be any number of native or custom apps, or they might be APIs that are used by other systems.
But what’s important is that Salesforce’s place as a System of Record gives them the right to influence the Systems of Engagement. In its infancy, the Salesforce.com application served as both the System of Record and System of Engagement. But the modern software landscape is far more complex, and the methods of engagement are becoming increasingly heterogeneous.
The reason Salesforce truly cares about this
When Salesforce was a small upstart throwing punches at the much larger Oracle and Siebel, end users didn’t have much choice into what software they used. Cloud was in its infancy, and most software was still on premises. A company’s IT organization would decide what you used, and you’d use it.
Things are different now — the pace of software creation and adoption is far more rapid, and users expect modern, customer-friendly experiences. If they’re not provided by IT, they’ll search them out themselves and before long, enterprise IT might find themselves in a procurement cycle to purchase the enterprise edition. Why does this matter? It means that the systems of record and systems of engagement are increasingly being decoupled.
Data might have gravity, but relying on the primacy of your system as the data store at the expense of user experience is a dangerous proposition. There are two approaches to take when faced with this proposition — entrench your position as the system of record and engagement, or create a platform that allows for myriad systems of engagement, while maintaining a hold on your place as the system of record.
If anyone can build against Salesforce data in the manner that they choose, why would you ever leave? If you provide the tools, both 1st and 3rd party, to support whatever interaction pattern your customer desires, they remain locked into your platform, for which you charge a per seat license for access. By creating an ecosystem around your system of record moat, you ensure that customers have no reason to leave. Consider the diagram below.
The alternate (and intentionally overly simplistic) approach for Salesforce helps to make this point — imagine that Salesforce data was only accessible through the default Salesforce.com views, and that you’re a customer that needed to support field reps that went door to door with mobile apps, and required a custom field that needed updating in real time.
Now imagine that Salesforce had a poor native mobile app, and did not support adequate pub/sub patterns that allowed for the specific field to be updated in real time. What is that customer to do? They would likely seek out an alternate CRM that better fits their market segment, or find a way to move their CRM data into a 3rd party app, and update the real-time field separately.
Essentially, they would start using a new app entirely, perhaps using copies of data from the CRM initially. This creates a wedge between the customer and Salesforce’s money maker — the system of record. That new app owns the customer relationship, and brings a new, more relevant data model. It’s not hard to imagine the next step, where that application then introduces its own backend data store, and ultimately disintermediates Salesforce entirely.
The beauty of the Salesforce model is that it’s already the default system of record — so by providing the platform, they allow innovation on the interaction methods by not just Salesforce itself, but their customers and all manner of 3rd parties (ISVs, system integrators, small development shops, consulting firms). This further entrenches Salesforce as a platform, as each incremental use case and engagement method creates additional value and increased costs to switch.
The centrality of middleware
What is middleware, you might be tempted to ask? Middleware is the word you say when you want to determine whether someone really spends time thinking about enterprise systems and architecture, or just likes to pretend.
Middleware is a broad bucket that includes the various sorts of software that connect different applications and data sources together. Integration products of various kinds, API management, and message brokers all fall into this category. If it connects two systems together, it’s likely middleware. It’s in the middle — hence the name. (application servers are another piece of this middleware puzzle, but that is a topic for another time).
Often maligned by the broader investment community, and generally considered to be boring, messy, tedious, and not worth the headache... until it’s not. Like middleware products themselves, it’s a category that’s often ignored, and usually just assumed to be covered by someone else.
But as systems become more complicated, and environments become more heterogeneous and hybrid, layers of middleware become fantastically important when you consider that most companies use hundreds of applications, and that those applications are rarely useful when they exist in a vacuum, unconnected to the broader company’s systems, processes, and data models.
Most middleware products begin as standalone companies, which makes sense when you consider the value prop — middleware is Switzerland — brokering data between different entities so that applications are kept in sync, data gets to all of the places that it needs to, and you don’t need to manage the data contained in each of your applications and data stores separately.
When a customer goes from prospect to closed customer, you don’t want to update that in your CRM and your email marketing system manually. Your CRM should let your marketing systems know that the deal has closed, to spare them the pain of a continued email drip campaign. And your ERP system will want to know that you’ve closed a new customer so that you can update your billing and forecasting.
Every customer has their own mix of these enterprise apps, and they use middleware (which provides connectors of sorts to each of these) to connect them. In this scenario, it should be clear why middleware tends to be neutral. You generally don’t want your integration product to have opinions about where data should go, you just want it to match the patterns that are required by your business. There are a lot of examples of phenomenal standalone businesses built in the middleware market.
But as noted earlier, there is also a well established trend of these being acquired for very large sums of money, thereby forfeiting the Switzerland label, which can be argued is core to the value prop of the business’ entire reason for being.
So why pay an acquisition premium for Switzerland, thereby destroying it’s very swissness? The answer is platforms, and more specifically, data models and systems of record. By owning the middleware layers, you have an influence and an ability to export your data model from your system of record to every other would-be system of record that the customer has adopted.
It gives you a say in how every aspect of a customer’s business is viewed. Every application encodes a process — opinionated middleware ensures that all of those processes tie back to your central system of record. You get to export your point of view. To everything. It’s a friction remover for the horizontal expansion of your platform across systems. You rarely force them to change anything, but you ensure that the paths of least resistance are in your favor. And you prevent competitors from doing the inverse.
So… back to Salesforce. Why does Salesforce acquire Mulesoft? Because it’s in Salesforce’s best interest that every application that will ever exist on earth connects very easily with Salesforce. And that any application that’s built on top of the Salesforce platform can connect with these other applications, so that the Salesforce system of record reigns supreme and is at the center of every incremental thing you do with your customer.
While $6.5B for a boring integration company might sound like a lot at first blush, $6.5B to protect and export the supremacy of your system of record should not. Systems of Record have gravity, Mulesoft makes that gravitational pull significantly stronger.
It should not, however, be assumed Mulesoft was acquired solely to expand Salesforce’s platform ambitions. Mulesoft is a strong player in multiple middleware categories — ESB, iPaaS, and API Management, each of which are large and growing markets. The strength of the Salesforce go to market machine, combined with the centrality of the Salesforce platform to most enterprise integration architectures and strategies, has provided a significant acceleration of the Mulesoft revenue trajectory.
This is the power of the platform — and why platforms can acquire for prices that seem crazy to others. They are playing with a fundamentally different incentive structure, and have access to additional levers of customer value and monetization that a standalone product does not.
Enter low code and no code
The genesis of this essay was actually a reluctant desire to fire off a series of frustrated tweets explaining why a lot of the discussion around low code and no code is misguided, at best. Like cloud, low code (we’ll call it that for short — but it refers to both low and no-code; the differences between those require a whole different essay) is a theme or trend, and not a category itself.
Like saying “we are a cloud company,” the statement that “we are a low-code company” tells you almost nothing about what value the company’s products actually provide. Cloud is a deployment method, a mode of operating, and is maybe related to cloud-native, kubernetes, and other recent trendy words. Low code is a user interface and application customization paradigm, which exists across every application category.
So why does this matter? Let’s revisit a diagram from earlier, which shows the Salesforce platform and their ability to theoretically deliver whatever applications a customer needs. You probably hear more about the Salesforce’s apps and AppExchange apps than you do Lightning Apps.
Why is this? Probably because the Lightning App platform is new(ish), not particularly great, and very Salesforce ecosystem centric. Not a lot of people openly profess love for Salesforce on Twitter, or anywhere else, for that matter. But Lightning, and tools like it, are a glimpse into the future of enterprise applications.
As asserted earlier, enterprise software exists predominantly to structure and enable a process, and brings an opinion to how that process is to be done. If you’re a small business, you customize that logic in something like a spreadsheet. If you’re a large business, you might implement Salesforce and pay some consultants a bunch of money to go spend 6 months customizing it to something that resembles how your process works (and you might even change your process to bring the last 10% into line).
All an application really is though, is a UX on a relational database. That “database” could be a spreadsheet, or it could be whatever database Salesforce embeds in their product to store all of your data (which I assume to be a bunch of Oracle, and maybe some Postgres?).
Additionally, in a modern world, that “database” against which you’re building applications is more likely to be a number of smaller “databases” underlying the various products and tools with which you run your business and interact with customers and users.
So if you’ll take a small intellectual leap, what low code really is, is a semi opinionated UX customization layer that sits on top of that database. Instead of requiring Salesforce, or a partner on the AppExchange, or Salesforce consultants to build the app that resembles the process you have in your head, you can build it yourself with a set of tools that consist of some mix of drag and drop elements, forms, lists, and other modular building blocks for an application.
This allows you to build the application or workflow that is required for your specific use case for your specific user. Gone are the “a couple sizes fit most” days of enterprise applications. Enter “endless customization” of enterprise applications.
What apps will you build? Well, return to your Salesforce platform, Mulesoft-enabled ecosystem. In theory, you build anything, because you are building on top of the Salesforce data model, which has been out-of-the-box enabled to talk to integrate with any other application that you desire.
Having said that, it’s worth noting that there’s a whole incentive structure attached to what Salesforce wants its users to do, and as you might imagine, it’s predicated on driving Salesforce seats and tier upsells. So while Salesforce, and many others, may have “functionally verticalized” low code platforms, they’ll be inherently biased towards their own properties (it’s my opinion that no amount of focus gives you a reasonable expectation of succeeding to build a truly un-opinionated product of this type inside a company the size of Salesforce. You may disagree with this.)
This opens the door to horizontal low code platforms, which can be viewed like very opinionated IDEs or application development languages, sitting on top of whatever data sources an enterprise desires (databases, usually). It should be noted that this is a reemerging trend, but it is not a new one. (In technology, nothing is ever really new.)
[February 7th edit: the acquisition of Slack by Salesforce in December 2020 is an example of the company’s understanding of this trend. Slack in this case should be thought of as providing a new set of interaction patterns on top of the Salesforce data model. The Slack product has a great API and a robust ecosystem of integrations, and is becoming more important as a central hub for business process. The purchase price was relatively expensive, but the acquisition is bold move that will likely be viewed in the long term as a positive (plus, Salesforce has historically been phenomenal at M&A integration). It also provides a lot of confidence that the management team fully understands the direction that their platform must aggressively be moving.]
A glimpse into one potential future
We’ve until now discussed the strength of the Salesforce platform, and laid out a solid case for being very, very long Salesforce. And while the author is long Salesforce, explaining why the leader is going to keep leading is no fun, so we’ll now make the case, along the same lines already established, for the vulnerability of Salesforce.
If you ask Salesforce themselves what their company does, you get the following answer — they help you interact with your customers.
Salesforce is really about two things — helping you to interact with your customers (system of engagement), and helping you to catalogue those interactions (system of record). Given its heritage, a lot of this is done fairly relationally — customers are records, with a bunch of different attributes — location, size, revenue, industry, with a lot of associated actions — emails, phone calls, descriptions of point in time disposition towards buying your product.
But the world has changed quite a bit since the late 90s, and the number of methods for interacting with customers has blossomed. Many deals are closed with steak dinners, but products are increasingly purchased, not sold. You’ll struggle to find a hotter 2021 buzzword than “product led growth,” and you’ll surely be able to find a number of investors and writers who are happy to profusely extol the virtues of the model (so I’ll spare you).
With this in mind, consider the following:
Enterprise sales has a lot more in common with B2C sales than it ever has. Free trials are expected. Customers will be familiar with your product, and maybe even using it in production, for months or years before they ever speak to a sales rep.
Your customer has hundreds of interactions with your product before they show up on your radar — through Google searches, through personal email free trials, through causal browsing of the pricing page on your website.
Sales and marketing are far closer cousins than at any point in the past. Marketing can convert leads to closed contracts of significant size through online sign ups without sales ever being involved.
The days of linearly scaling enterprise exec heavy sales teams cost effectively blasting unsuspecting victims with InMails is likely a thing of the past.
Then, consider that every business will increasingly expect to have access to applications that allow them to transact in the manner that suits their specific business and mental models, not a set of semi-rigid pre-provided pages and views.
If the application UX for how you manage and view customer relationships has changed, and the methods by which you engage with customers has changed, if you really squint, what is Salesforce other than a repository of relational customer data that describes what has already happened?
But what if a single software vendor could provide the full spectrum of communication channels — text, chat, email, telephony, available programmatically through APIs.
Layer this on top of a platform that integrated across the tools that modern businesses use to interact, in the broadest sense, with their customers — Google Ads, Facebook Ads, Stripe, Zendesk, Salesforce, Marketo, Hubspot, Intercom, Braze, Mixpanel.
On all of this, imagine a graph of all engagement and activity, tailored specifically to a customer based on their own company’s data model (what matters to them, and how they describe it), all of which is accessible to act on via APIs or query with existing analytics tools.
And then below, everything is persisted in a semi-structured database, managed either by the company or the customer.
Lastly, imagine that on top of this whole platform existed packaged apps for running contact centers or marketing automation, as well as a low code development environment for creating workflows and applications on the customer’s specific data model.
Now, consider Twilio + Segment, which to date, already offers everything excluding the persistent backend, and the low code development platform.
What makes this even remotely possible, such that it’s worth discussing? Interactions are far less relational than they once were. The Salesforce model is understandably built from the bottom up, where the source of truth is the customer record. But the customer record is built on a set of interactions that are occurring, constantly, outside the purview of the Salesforce platform.
Data may have gravity, but backwards looking data stored in a relational database is rarely as useful as insights into what your customer is doing now, and what they might be wanting to do in the future. That data, to the detriment of Salesforce, is created and acted on elsewhere.
If the engagement channels change, and the data model for viewing, structuring, and managing those interactions changes, what more is Salesforce than a database of customer interactions that are occurring elsewhere?
Perhaps most importantly, is that Salesforce has a structural incentive to sell more licenses for seats of their underlying platform. Salesforce wins when you buy more Salesforce seats. Twilio has no incumbent CRM revenue model to protect, their platform is a top down re-architecture of the customer engagement model, unwedded to underlying relational records and interactions therewith.
This dynamic — the continued decoupling of the creation and engagement with data from the storage and structuring of that data — leaves all incumbent enterprise applications vulnerable to low code vendors in the long term. Many likely will begin life as customization platforms on top of those incumbents.
Consider a “low code for sales” application that sits on top of Salesforce, and leverages, but also brings an opinion to the data model, and then allows for applications to be created not only against Salesforce, but other applications, including maybe an Adobe CRM that’s still in place due to an acquisition years earlier.
What makes this different from the current world of custom, internally developed CRM apps is that what used to require development teams and months, could now require one developer and a few weeks. Because these vendors don’t have to reinvent the CRM. We generally know what purpose one of those serves. What they reinvent is the way you interact with your CRM.
Customer interactions drive business value, while the underlying database decisions very rarely do. The modern company seeks to innovate at the top of the stack, close to the customer, not the bottom. The potential Twilio customer engagement platform rethinks these interactions and opens the door to an infinite number of signals, not just those that fit nicely into a relational paradigm.
This does not happen overnight. But it is a trend that brings asymmetrical threats to the gates of Salesforce, and every other incumbent application vendor. And in 20 years, the successor to Salesforce, by then anointed the New Platform, will face a similar thematic challenge from a different wedge.
Companies that embrace innovation tend to outperform, and the world’s largest companies in the coming years will expect more from their applications than the world’s largest companies do today. To borrow a phrase from an earlier marketing campaign by my current employer, "Adapt or Die."
But, in this modern world, is Salesforce not just an expensive, $150 per employee deployment of Postgres?
Thank you to Natalie, John, Diana, Casey, Sudheendra, and Chris for providing feedback, edits, and in some cases, emotional support.
Phenomenal analysis. Doesn't it just make sense for CRM to try and take out TWLO? Could be construed as a merger. Jeff Lawson would make a formidable future heir to the combined entity.
This is gold!!!!!