Let’s say you want to create a new digital platform to help travellers. This platform should link the traveller (or customer) to certain activities, guides, accommodations, vehicles and/or a driver.
To develop such a platform, you need to involve many different stakeholders all coming from a different background. A management having an economical background, the database developers, the User Interface developers, local governments, legal consultants, other employees and etc. If you have experience in software development we can agree that getting all these stakeholders involved causes major communication issues . In the domain of digital platforms these communication issues are even more problematic. First, the term ‘digital platform’ is overloaded, it can mean almost anything. Second, the terminology and definitions of different kinds of digital platform (called ‘platform types’) including ‘sharing economy platform’, ‘on-demand platform’ and ‘multi-sided platform’ are overloaded as well, making it hard to classify your software and find related research. Third, especially when a platform targets multiple user groups (a.k.a multi-sided markets), it is hard to explain the difference between the user types including ‘customers’, ‘providers’, ‘Guide’, ‘Driver’, ‘Car Owner’ etc.
Solution: Digital Platform Ontology
A solution to these issues is the creation of an ontology (model), a visual representation of the entities and relationships of your digital platform. By making a difference between objects, user roles, social constructs and events, it is easier for stakeholders with a different background to communicate using this ontology model. Here is a general (or high-level) ontology of all digital platform, independent of its type:
The objects (in red) indicate the software and different stakeholders (e.g. owner, management, user) of a platform.
The events (in yellow) can be divided into three main groups:
- User actions: These actions always involve a user, and are important for the developers to create the user interfaces, with a clear visual what kind of users (depending on their role) should be allowed to access what interface/functionality. Typically during the development of the software web developers are involved using Angular, React or Ruby on Rails
- Platform Software action: These actions only involve the software, and are data driven. An example is the distribution of Uber drivers to customers. The development of these events into software typically involves data-driven developers using Java or Python
- Platform Management Action: These actions involve employees, and are typically back-end interfaces directly connected to the database. This involves Node.js and/or update sql queries.
The social entities (green) indicate a social construct between the objects. For example an offering, a transaction or an insurance. These concepts are primarily regulation-driven.
The general ontology model gives a high-level representation of all models. But depending on the type, your platform can have/need different requirements and functionality. For example a sharing economy platform like Airbnb works differently than an on-demand platform like Uber. The following taxonomy gives an overview of how digital platform types can differ from each other. More info on this taxonomy can be found on this link.
For each property value, we created an ontology module. When you have chosen the right property values of your intended platform, use the compliant ontology modules to create a full ontology model of your platform idea. These ontology modules are like building blocks. By organising the ontology into modules, it is possible to select and combine modules, create new ones and increase the possible functionalities of the model. As a result, our reference ontology can accommodate the evolution of the digital platform domain and combine existing and emerging platform variations to model new types.
Example: Uber Eats
As a proof-of-concept of how the ontology model helps understanding digital platforms and improve the communication, we discuss Uber Eats, a platform for food delivery. As you can see below on the left, the process model is only capable of capturing the activities needed from the different user types to get the meal to the customer. On the other hand, the ontology model on the right also captures the functionalities and events (yellow), constraints (arrows and cardinalities) and social entities (green) of the Uber Eats Platform.
An Uber Eats Customer is considered both a platform customer and peer user. An Uber Eats Restaurant is considered both an offering creator and a an organisation. Both types of user need to be registered, but for a customer this registration is automated. A restaurant can create an offering (of the meals) on the platform called a ‘listing’. This listing is described by the listing descriptions. A customer can search through the listings overview and create a transaction that conforms to the offering on the platform. This transaction results in the preparation of the meal. An Uber Eats rider is considered a peer user. After registration, he delivers the meal to the customer.
Included a short summery video: