NB: This post originally appeared on Matt's substack

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.

https://cdn.substack.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F001c3b3e-5350-4abb-aae6-ba3491da72f5_856x424.png

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

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

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.

who

So, why does Salesforce care about this? or, systems of engagement versus systems of interaction