What is the Difference Between an Application and a Platform and Why it Matters?
Practically every SaaS vendor talks about their “platform”. Truth be told, most SaaS vendors are not platforms but merely providers of feature-rich applications. Why does this matter? Simply put, without an extensible, open platform, it will become increasingly difficult for application-only vendors to survive.
Lets start by defining “platform”. Back in the early days of SaaS, “platform” was often referred as a complete software programming development environment and underlying subsystem with language, run-time, components and all associated libraries and binaries. The result of using a platform (think Microsoft .NET or Java) was a software application.
About 10 years ago, the concept of a platform started to change. It became less of an underlying computer system and more of something that could be built upon and connect a broader ecosystem. The launch of the iPhone (2007), AWS (2006), and Force.com (2007) brought an entire re-thinking of what an “open platform” should be — something that can have different form factors, interconnect with other software streams, with capabilities to extend its current design and do things that were not originally intended at the time of its initial launch.
More recently, the emergence of micro-services architectures, combined with cloud services platforms (think AWS, Microsoft Azure, Google Cloud Platform) now enable companies to bifurcate the logic functions of applications so that an IT structure can be built for change. While many SaaS have hundreds (and in some cases, thousands) of features, the predefined business logic narrows their ultimate breadth of scope and the flexibility is limited to the modular design of the platform.
Unfortunately, there are a number of reasons why SaaS vendors struggle to make the transition to platform vendors. First, it time-consuming and resource intensive. While investing in a platform and its associated services open up an opportunity to clean up technical debt, fixing architectural issues “under the covers” are typically less exciting that new features that generate more excitement from customers, partners and analysts.
Second, its complex. Monolithic applications must be broken up into components and services and this can present a challenge when other features and applications are dependent on that code. This means re-architecting processes, re-writing code and creating new layers of services, security, etc. Additional complexity is layered on when the vendor has grown by acquisition and the code, design and architectures can vary widely. In a world increasingly dependent on machine learning, the ability to segregate process, data and content will be critical.
Last, vendors struggle to monetize from their platform investments. Do you monetize by selling a platform subscription? Do you monetize by usage? Do you monetize by pass-through revenue from the partner ecosystem? Do you monetize but charging more for existing applications? Very few SaaS vendors have gotten this right.
In my next post, I’ll describe what it is means to be an open platform, beyond just the tech, and the one vendor (yes…just one) in the broader HR Tech and Work technology space that is getting it right.