What is the Platform Economy? The market metaphor
Let’s start with a perhaps trivial but quite clear example: since human civilization began to produce goods and services, the need to exchange these products arose. It is the basic law of supply and demand in which the concept of the market plays a fundamental role. Without looking at the sophisticated mechanisms of financial markets, let’s take as a reference a normal local market: there is an infrastructure represented by the square where the market takes place, there are stalls where different products are offered for sale (fruit, vegetables, and so on), and there are people who ask to buy these products because they need them.
All of these elements, however, must be somehow organized and “regulated”: if a market sells only one type of product, which may not be of interest to a sufficient number of buyers, the transactions will not go well and it would close. Conversely, a market that offers quality, varied, and well-priced products would not work if it were hidden from the view of those who wish to purchase those products. Additionally, if some fruit or vegetable stalls are overcrowded to the point of making the buying process tiresome and too lengthy, the market does not function properly.
From Physical Market to Digital Business
If we transfer this metaphor to the current landscape of digital business, we see companies that have started from these considerations and have managed to create a system through which to connect the traditional physical world with a digital interface capable of “regulating” the supply and demand of a service/product. On one side, there is an offer of something; on the other, there is a demand for that “commodity”; in the middle is the platform that allows the two needs to meet as simply and straightforwardly as possible.
Think of Uber for the traditional taxi market, or Airbnb for short-term accommodation rentals: these companies have built an “infrastructure” that performs a complex role in matching supply and demand in the physical world through an easy-to-use digital interface for users, whether they are on the supply or demand side.
In these cases, it is evident that technology, which is fundamental to the entire business, plays “only” the role of service enabler: those looking for a car to take them to their destination or those renting out accommodation for a few days do not need to know the underlying technology, but simply use the platform’s interface.
In the case of Airbnb, for example, the “producers” offer homes, the “consumers” rent them, and the “platform” facilitates the meeting between the two needs (“match”). The platform’s “curators” ensure that things go smoothly in terms of service quality, security, and reliability of the parties involved.
Variations on the Theme
And there are not only these two striking examples: major sports apparel brands, for example, have brought their physical world (shoes, sportswear, etc.) into digital platforms. In this sense, we can consider the acquisitions of Runtastic by Adidas or Runkeeper by Asics, so they have their fitness tracking app just like what happens with Nike+ and its use on Apple’s Apple Watch.
To be precise, in the case of large sports equipment companies, the situation is somewhat different compared to the “neutral” platform represented by Uber or Airbnb, because here, the focus is not merely on connecting supply and demand, but rather on engaging a community with specific needs and offering them precise products. However, at the functional level, we are in the same domain: there is a platform easily accessible by the end-user, which also showcases a range of products that are easy to purchase with just a few simple steps.
From B2C to B2B
These Business to Consumer examples are well-known, work well—despite regulatory limitations that may affect a specific sector like taxis—and have been tried and tested for years by millions of users.
But, in addition to B2C, does it make sense to talk about platforms in a Business to Business context? Moving to the B2B world — which is where we often find ourselves working with Agile coaching — in recent years, we have become increasingly aware of how the platform economy can be truly crucial in the growth and evolution of companies.
In many cases, it has become clear that, beyond coaching interventions with people and adjusting the organization of work teams, companies lack an overall vision and a precise awareness of how to manage the life cycle of a digital service, which architectural style to adopt for their information systems, and how to handle the organization of information and data, which are increasingly heterogeneous, even considering all the prior legacy.
In some large companies, the development of many information systems over many years has resulted in an organization of people that ultimately mirrors the structure of those systems: it is difficult to change the organization without also changing what underlies it and has determined its current configuration.
Take, for example, a hypothetical banking institution: there could be two different business areas (financing for entrepreneurial initiatives and mortgages for private homes, just to mention) that have developed completely different approaches, systems, and data organization over the years, even though they engage in similar activities and could share information.
From Silos to Integration Architectures
This organization of vertical and independent software pieces nullifies all the possibilities of doing things better, represented by reuse, control, and data exchange. Every time synergy is needed, it becomes an isolated initiative: only specific sets of data are identified, aggregated, and related, and each time new aggregations are needed, a new project must be started. This is a huge cost: each time, work is redone to understand what information is needed, securely expose it, identify users using a particular service, propagate these services in a performant and scalable way, and so on.
It is clear that these problems arise because those services were not initially designed to be integrated or scaled. But this does not mean it cannot be done, and the key lies in decoupling the company’s core systems from the systems that expose processes and services externally (B2C) and internally (B2B) within the company. This is nothing new: client-server architectures first, and integration architectures like SOA later, have been addressing these problems for about twenty years now, but certainly in a way that is not conceptually and operationally simple, as those who use various SOA Service Registry and Repository know well.
Platform Economy for Companies
If we return to the topic of supply and demand, there is a lesson that platform-based services have taught us, which is to connect the two sides in a way that satisfies both, through an easy-to-use interface.
Many large companies possess data and information assets to offer not only externally, but also and especially internally. Often, this data is not immediately available but instead lies “buried” within the company’s information systems. The leap in quality comes from making the business and marketing sectors understand that there may be valuable data within the company on which to build new initiatives. However, this must be done in a “usable” way, and creating a platform capable of collecting, aggregating, and simply exposing this information is a possible solution.
IMAGE – The “spaghetti” architecture can be rationalized with a “platform” approach (image from mia-platform.eu).
For example, marketing must create a user experience-tailored service that is either already present or desired, and in this endeavor, it should not be “frustrated” by an IT department saying, “Nice, but it can’t be done because we don’t have the information, and it takes a long time to gather and make it available.” Instead, we must create a system that enables these types of operations, even with experiments, and in which all the assets created over the years at significant expense are valued.
The goal is to create a layer with clear rules – which we can define as API-centric and will see why later – in which APIs define the highest level of IT services.
An example: Google Maps
to understand the importance of well-exposed APIs, consider Google Maps. Nowadays, we find the classic map integrated into numerous applications, and geolocated data related to traffic, weather, businesses, and so on end up within a myriad of systems. However, the important thing is not just that this data is exposed by APIs easily used by IT; the important thing is that these APIs are also easily understandable by a company’s business and marketing departments, which may not know exactly how they work technically but perfectly understand what they do, what data they can offer, and that this data can be easily integrated into new applications. It’s a paradigm shift because now the business more easily connects, in an “agnostic” way, to the logic of the company’s data and components.
This is what B2B platform economy for companies entails: creating economies of scale from their data and services that are accessible to third parties. In this model, business and IT collaborate within the company to create value thanks to an API-centric platform that lies in the middle and remains open. The platform itself becomes the central asset for IT, and from it, business and marketing can conduct their initiatives and “experiments”; and there is nothing to prevent this from being done in outsourcing, involving other companies that still need to “hook into” APIs that expose the data.
Organization, architecture, technology
Creating a platform of this kind obviously requires a set of “prerequisites” in terms of the organization of development teams, architectural style, and technologies used, as well as careful planning of investments and the business model, bearing in mind that this business model can also be cost-saving.
- Organization
At an organizational level, a platform assumes having cross-functional teams, as recommended by agile methodologies and particularly Scrum, which are responsible for the entire lifecycle of the service and are vertical, meaning they are tied to one or more services. These teams focus on developing something for the user, whether it be an API or a complete service.
- Cross-functional teams represent the organizational foundation for implementing a platform.
Furthermore, these “service teams” work together on the platform, evolving it. So, there is a platform code that develops thanks to the contributions of multiple teams throughout the lifecycle. A fundamental aspect is that the platform code is clearly distinguished, even at the repository level, from the code of individual services, which are the responsibility of individual teams and are well decoupled from the platform, residing in separate repositories.
The lifecycles of services will follow the principles of continuous integration, continuous delivery, and continuous deployment. In this sense, having a platform that these services rely on amplifies the scope of various “continuous” activities: for example, continuous delivery allows for ongoing releases, even during a pre-testing phase, to better collect requirements from the business.
An example of a pipeline for continuous delivery/deployment.
With an automated pipeline that puts written code into pre-production, it will be possible to see the results in a very short time. Continuous deployment represents the production release, which, with these premises, loses the features of an “event” but becomes a normal activity in the continuous cycle of creation, evaluation, and production of software made possible by the automated pipeline and the fact that the platform exposes a data model and provides the opportunity to connect to it from the embryonic stages of creating a service.
- Architecture
At the architectural level, the current most recommended and “celebrated” style is the microservices approach, which essentially involves adequate decoupling of services, limited to their application context. It is clear that it is also possible to aggregate and modify the granularity of microservices, but they should always be designed as cloud-native: even if our platform ultimately remains on an internal datacenter within the company, it is important that it possesses the characteristics to be natively cloud (isolated sessions per service and not cross-services, appropriate choice of filesystem persistence, etc.).
Microservices architecture diagram: in this case, the logical example of mia-platform is shown.
- Technology
Having discussed cloud, it becomes evident that we should build our platform on container systems, which become a true ally in isolating processes and logic from those who expose these services at the infrastructure level. Docker and Kubernetes are now established and reliable tools and are currently very popular, although we cannot know for certain what will happen in five or ten years.
Another important technological aspect in platforms is the backend-frontend decoupling, because we cannot know on which end device the service will be consumed. However, even if the user interface changes with which the service is used and new devices are created, the underlying data model and application logic remain unchanged. This is the strength of the platform and the Open API model, which must be documented according to precise criteria and must be independent of the programming language that exposes them and the one that consumes them.
In any case, we must also think evolutionarily with technology, because the language we use today may not be the one used in ten years. Being able to create a polyglot microservices platform, that is, a multilingual platform, is insurance for the future, as it allows choosing the most suitable technology today without preventing the continued use of existing components tomorrow, without having to rewrite everything.
To sum it all up, we should create a platform that is API-centric with respect to technology and user-centric at the business level.
The Lesson from the Platform Economy
What we have learned from the success of global platform economy initiatives can be transferred within companies to create platforms capable of connecting an offer (of data, information, etc.) with demand from the business and marketing sectors for the development of useful services that create value for the company. Clearly, this primarily applies to large companies, but it would be misleading to think of it only in terms of enterprise scale: the importance of this type of approach for innovative companies such as startups should not be underestimated
To know more about Platform Economy, we recommend you to read this article written by Mia-Platform Team
