“The only simplicity for which I would give a straw is that which is on the other side of the complex.”

— Oliver Wendell Holmes Jr.*

At Forrester, we’ve periodically debated the meaning of the word “platform,” and it’s been challenging. Common ground has eluded those who cover ecosystems such as Amazon and Salesforce versus those covering platform engineering.

Recently, we’ve been discussing this common definition of platform: “a product that supports the creation and/or delivery of other products.” The following diagram illustrates this concept:

The acid test for a unified definition of “platform”: What can we say that would be true both of the Amazon retail ecosystem as well as Amazon Web Services?

Well, what do a new Amazon storefront and a new AWS account have in common? Both of them are going to require a lot more investment by their owners to deliver any value. An empty Amazon storefront? You need to figure out your product mix, supply chain, pricing, marketing, etc. Amazon gives you a lot of help, but you have much work ahead of you in configuring the platform for value. An AWS account? Empty EC2 virtual machines or Lambda functions? Not doing anyone much good until you install and run software and surround those workloads with a lot of additional capabilities.

So we can say that platforms, in general, require further investment, and the result of such investment is typically value-generating capability. It’s also well established that platforms are products (see Team Topologies and other sources). Therefore, in a world pivoting to the product model, it seems reasonable to simply say that the platform is a product that is creating, or supporting the delivery of, other products.

We also see platforms as either “infrastructure” or “business.” Sometimes a given vendor provides both — Salesforce with Force.com as an infrastructure platform (a platform as a service, in the classic definition), Agentforce for CRM, etc. Note that both require serious investment to get going (and this is not a criticism of Salesforce; it’s just a general observation that you’re not going to have a functioning CRM capability without investing substantial setup effort).

The boundary here is simple: Infrastructure is business-agnostic (in general, it could work in various industry verticals) while a business platform embeds business-meaningful semantics in the form of APIs, data, or services. Customer relationship management, supply chain, pricing, payment sales funnels — these are all business-specific concepts, and if that’s what’s on offer, you have a business platform. (Some nuance in the above diagram: Business platforms may support constructed apps or be directly configured for consumer access, but in either case, it’s effort, and for me, it’s “application” by definition if the end consumer is interacting directly.)

Finally, I can already feel the eyebrows raising at the inclusion of “application.” I’ll be talking more about this as we update Forrester’s Four-Lifecycle Model, but for now, I’ll just say:

  • If platforms are “products,” then we need a specific label for products that are not platforms (data geeks will recognize the subtyping problem). And with due respect to Team Topologies, I have not seen the term “stream-aligned” get traction in portfolio management.
  • Conversely, the term “application” is here to stay and has a reasonably consistent industry meaning, at least in the discussions I have with IT leaders — more on this later.

Finally, this model is part of the Forrester Platform Engineering Capability Model, just released last week. I’ll be doing another blog on the core of that work. Also, be sure to check out Embrace Platform Org Structures To Break Down Silos And Deliver Scale, also just out this month, which I coauthored with Manuel Geitz!

*Wikiquote notes: “Often quoted as ‘I wouldn’t give a fig for the simplicity on this side of complexity; I would give my right arm for the simplicity on the far side of complexity’ and attributed to Oliver Wendell Holmes, Sr.”