In my experience, everyone who has worked on a software development project with multiple stakeholders has encountered the difficulties of communication. Developing a software based on a business plan, and taking into account legal, social and other non-technical requirements needs close collaboration between stakeholders with a different background (Economists, developers, legal consultants, …), and that’s not an easy job.

Let me show this with an example: You want to create a new digital platform to connect travellers with certain activities, guides, accommodations, vehicles and/or a driver. This envisioned platform could offer a wide range of functionalities including communication between the user sides, time-related booking, payments, reviews and many more.

To develop such a platform, you need to involve many different stakeholders all coming from a different background. A management team, strategy architects, a product manager, database developers, user interface designers, local governments, legal consultants, future users and many more. Without the involvement of all stakeholders the developed product will have shortcomings, but involving all these stakeholders causes major communication problems; 

First of all, the term ‘digital platform’ is overloaded, it can mean almost anything. Maybe the management and de software developers have a completely different idea of what a ‘platform’ is.

Second, the terminology and definitions of different kinds of digital platform (a.k.a ‘platform types’) including ‘sharing economy platform’, ‘on-demand platform’ and ‘multi-sided platform’ are overloaded as well, making it hard to classify your platform and information tailored to your needs. 

Third, especially when a platform operated in a multi-sided market and plans to target multiple user groups it is hard to clarify the user types (think of customers, travellers, providers, activities, guides, drivers, vehicles, vehicle owners with possible overlap) and the envisioned functionalities and constraints linked to these user types.

Possible Solution: Ontology Model

During my research I found a possible solution to these problems; An ontology model. This is a visual representation of the entities and relationships aiding in the creation of the envisioned digital platform. First, by visualising the difference between objects, user roles, social constructs and events, improving the communication between stakeholders of a different background. Second, by driving software development due to the clear representation of data requirements, constraints and envisioned functionality. For example, the (partial) ontology below gives a good overview of what a digital platform is, and what is related to it.

Our model is based on Unified Modelling Language (UML) and extended to capture more than only data requirements. Objects (in red) can be software or stakeholders (management, user) of a platform. Objects are bound to each other via social constructs (in green). It is the platform management that offers the digital platform towards a target user community. After, a platform user can bound itself to the platform via an affiliation agreement. This affiliation (e.g. by registration, subscription, transaction, …) is dependent on the platform type and will be elaborated later on. Due to these social constructs our model is able to capture and link information primarily important in a legal context. An object can also participate in or support events (in yellow). In this model all events are supported by software (it is a DIGITAL platform after all) and can be categorised into three main groups:

• User actions: Performed by a user, and indicate the user functionality, or user interfaces of the platform. The implementation of these events typically involve programming languages like CSS, HTML, Javascript and Typescript using a web application framework like Angular, React or Rails.
• Platform Software actions: Supported by the platform software without any human interaction. An example is the distribution of Uber drivers to customers. The implementation of these data-driven events typically involve programming languages like Java or Python
• Platform Management Actions: Performed by employees of the platform company, and are typically back-end interfaces directly connected to the database. The implementation of these events involve typically involve Node.js and/or update sql queries.

Visualise the Difference

The platform ontology above gives a high-level representation of all platform types. But depending on the type, your platform will 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 information on this taxonomy can be found here.

For each property value, we created an ontology module. These ontology modules can then be combined with each other, like building blocks. When you have chosen the right property values of your envisioned platform, use the compliant ontology modules to create a full ontology model of your platform idea. By organising the ontology into modules, it is possible to apply and combine modules, create new ones and increase the possible functionalities of the model. As a result, the 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 shortly discuss Uber Eats, a platform for food delivery. As you can see below, 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 below not only captures the functionalities and events (yellow) and user types (red) but also relations (arrows), constraints (e.g. 0..*; 1..*; 1;…) and social entities (green) of the Uber Eats platform. For example, the model defines the difference between offering, listing, listing description, listing overview and listing search. It also shows that the transaction leads to both the preparation of the mail, related to the predefined listing, and the delivery of the meal by an automatically matched rider.

We conclude with a short explanatory video. More videos can be found here.