Platform Business Models
Software Platforms, like all software, can be delivered in several ways to serve their users and so, they may be used in different ways to generate revenue. We can basically differentiate the following fundamental business models for platforms:
- Company internal solution business – shared cost model: Internal re-use of SW that should speed up development for solutions in solution business. Platform cost is shared across projects and solutions. The platform itself is seen as a pure cost factor, revenue is generated only by solutions on top of it.
- Company internal product business – shared cost model: Internal re-use in product line approach where the platform provides core elements to all products within the product line. Platform cost is shared between products. The platform itself is seen as a pure cost factor, revenue is generated only by solutions on top of it.
- Company internal product or service – platform has own loss and profit responsibility. Here the platform is managed as a product with an internal price which may be pay-per-use, perpetual or fixed-price oriented. Only works when used in large enterprises across many departments to gain enough reuse.
- Platform as a licensed (at a price or free to use) product offering, providing a set of tools and modules that build the basis for further development. You will find many vendors who call their products a platform because you can develop more sophisticated products based on their product. Typically, this requires local installation / provisioning through download or media.
- External, public, managed service offering, typically based on pay-per-use consumption models or subscription models. Target here is to maximize amount of users of the platform via online usage. This is where AWS and other cloud providers are at home.
Please note that the business model differs from the deployment model. You can host internal platforms as well as external, commercialized services.
What all business models share in common is that it shall be used by 2 or more solutions or products, that the platform cost is somehow distributed over all users and so price typically lowers with more adoption. And because the fundamental model is based on maximizing the re-use, a failure of platform service may lead to massive impact at all users. So, failing to meet basic operational quality will have a killing effect on any platform business. The platform needs special attention in all aspects during the planning, the development and the operations processes. Operational qualities like security, scalability, multi-tenancy, robustness, cost efficiency and long term developer support become the key elements that drive success or failure.
For the sake of completeness, I also want to mention another concept of platform business models which focuses on platforms that aim to provide a convenient way to connect providers of a good / resource / service to those who want to consume and pay for such a good / resource / service. Examples are the following:
- Uber: Uber does not own cars, taxies or busses but provides a platform for people who want to offer a car and a driver and those who want to order a transportation ride.
- AirBnB: This company does not own hotels or rooms to rent but provides a platform for those who offer space and those who need it.
- eBay: Also here, eBay focuses on making it easy to sell and buy things, while eBay is only the intermediate enabler, not seller or buyer itself.
There are more examples for these platforms which all have in common that they provide functionality that enables other companies or people to make business – in a specific domain – via the platform. Those platforms are different from the ones I outlined above, because their main users are not solution builders and software developers but actual end users on two sides: The provider / producer side and the consumer side. Like platforms in other domains, e.g. Facebook as social platform, these platforms are out of scope for the remainder of this article. Any business which calls them self a software platform business, so can be categorized into a) the delivery of re-usable software components & services or b) the goal to enable providers and consumers of software or data to exchange their goods and execute sales/provisioning as easy as possible. That should not be mixed up.
Why do we want a Software Platform anyway?
Some typical Examples how Platforms emerge:
As a starting point, it shall be discussed how a business owner or R&D manager might come up with the idea of wanting a platform. In many, but not all, cases this starts with the idea of extracting the common features, qualities or data of existing solution or products into a platform. The examples are simplified but hopefully help to get a grip on the topic:
Multiple solutions or products in the same domain
Organizations that build and own multiple products within the same business domain, consider platforms as a mean to optimize development cost, operational cost and reduce time to market for new products. Here, the common functionality of all products in that product line (see PLE) becomes scope of the platform. Think of a series of cars which share the same chassis, motors and other parts. The same applies for solution business, where several solutions within the same business domain require a common set of functionality. Business drivers here are cost and time reduction for custom solutions, to gain a competitive advantage during bid phases and save cost during development. An additional motivation can be to ensure a common user experience across multiple products, e.g. implementing a single-sign-on mechanisms or reusable UI elements. But also here, the commercial idea of „save money through reuse“ is the key factor.
Multiple solutions or products in similar domains
Organizations that serve multiple business domains that share some common functionality expand the concept from one product line to many product lines and from one set of solutions to multiple. For example, in logistics you need to transport goods from A to B. More specialized, transporting food may be a bit different than transporting steel coils. More abstract or generic functionality with even broader adoption.
Carving in or buying products that complete your portfolio
In larger organizations it can happen that a software solution or product is bought along with the department which created it to complete a product portfolio. The same situation applies when two departments which were formerly independent are merged into a single department. The two department’s products will now be under the responsibility of a single head – with the need to optimize cost over all developments. Both parties might have common functionality in their portfolio where the organization may consider consolidation into a shared platform, to reduce development and maintenance cost. Another approach is integration, but that shall not be in focus now.
Leveraging USPs of existing Products
Looking at the history of Amazon Web Services, the platform was born when the architecture for the online web shop of Amazon.com was changed massively from a more monolithic solution to a more micro-service oriented solution. Service integration was required at large scale, which resulted in a messaging infrastructure known as Amazon Simple Queue Service (SQS). Also provisioning of scaleable compute, storage and network was required which allowed to rent out free capacities in data centers to 3rd parties over the year. This is now the Elastic Compute Cloud (EC2). So, Amazon managed to standardize and externalize core elements of their super-high scale and effective web-shop solution into a platform business. The USPs of these services were and still are their high operational qualities which are valued by millions of users every day. There are more examples from the open source world; e.g. Kafka emerged as an own messaging system product out of development at LinkedIn because they solved the problem of messaging at massive scale and then successfully lifted the point solution into an independent software product which is now maintained as main project under the Apache foundation.
Leveraging data that was collected in a successful Project
Let’s assume a company builds control and monitoring systems for larger industrial plants. Within this control and monitoring systems (also called SCADA systems; Supervisory, Control and Data Acquisition), which runs on premises of the plant, there is a huge amount of data that is basically not automatically leveraged yet. Now this company realized that there is a business opportunity to analyze the data and build recommendations from it how to run the plant more efficiently, or with less errors. They build a simple product that collects the data into a central place from the plants (e.g. a cloud based storage like AWS S3), analyze the data for a specific problem to solve and successfully created actionable insights. The customer likes it and a new business was born; a great success. Now, the business owners want more, the data that was collected promises more businesses that leverage data analytics so the data shall be re-used. Starting small this company then realizes over time that the data collection, cleansing and storage has a cost which should be shared between the new businesses. Also, data access needs to be controlled and the ever growing data catalog needs to be maintained and curated for effective use. So they start to implement functionality – services around the data pool for the management, providing common implementations to recurring task that pop up in all the new solutions. They also think of re-using some of the features from the first product in the new solutions. So, they actually started to build a data provider / data distribution platform around their data collection.
Assumed Benefits
The assumed benefits for creating a platform are often the same as for any platform development project. The platform development tries to foster reuse of functionality that is needed more than once in order to reduce maintenance and development cost or build new revenue channels around already developed services and existing data. Maintenance is the costliest part in a software life cycle and so any duplication of work has direct impact to the economic profit of an organization. Studies show, that 70% to 90% of the cost for operating a software product in the market are generated after the first release, mainly driven by the staff that is required to operate, service, maintain and extend the product. Also, if features are provided as shared components in a platform, new products and solutions are expected to be ready more quickly when built on top of it which also reduces time-to-market. Especially time-to-market is a crucial aspect for many business strategies and so is often highly prioritized. Today, speed and ability to adopt to a changing market is considered as key capabilities of successful companies.
In another direction businesses focus on the technological innovation and leveraging of USPs to build a new business. Such a business decision then is not directly influenced by a comparison on existing functionality over multiple solutions but is driven by the idea of leveraging the company’s USPs from the existing solutions. So the business case is more directed by strengthening the market positioning or entering new market segments, rather than reducing development cost and time-to-market in the first place. Typical examples are platforms that implement a new innovative technology or follow technological trends (e.g. virtualization, cloud computing, IOT, big data, multi core, mobile computing and similar). Nevertheless, reuse is in scope, because also the new technology needs to be used often, in order to compensate the research, development and operational cost. But here externalized, commercial reuse is the primary element.
Intuitively, people find it easy to believe that re-use can lead to substantial cost reductions. As early as 1988 Gaffney et al. set out to study the relationship between the relative costs of re-use and tried to determine the effects of amortizing the costs and benefits across many re-users (in this article, the re-users are called clients or users of the platform). To explain this relationship, they created the Payoff Threshold. The Payoff Threshold tells us how many times we have to re-use a component before we recover the investment we made in order to develop the shared component. Today, it is well understood that the number of re-uses has substantial impact on the question if it was worth to build a reusable component that can be used by developers to build products and solutions. But what not shall be forgotten is that not only creating a reusable component is costly but also to make people re-use it. You need to do marketing, sell your idea, manage dependencies, provide service and support and much more.
Building shared components and services is far more complex that building the same functionality for just one product or solution. This fact has its foundation in the increased efforts in requirements engineering, stakeholder management, testing and addressing a set of far more complex operational requirements. Specifically, the fact that you need to make sure that no one single platform user can cause a negative impact to any other platform users just by (miss-) using it, generates a lot of complex requirements (this effect is also called the „noisy neighbor effect„). The exact number of course is dependent on the concrete situation, but you can assume that it takes at least 3-5 times more effort to build such shared services in relation to a single-use of the same feature in a single product.
In the following articles we will discuss several aspects that make the platform approach for existing solutions complex and costly and how we can come closer to a realistic Payoff Threshold as mentioned above.
You need to be aware of the cost drivers in platform development to make a business case that survives.