In 2013, BMW and Toyota announced a joint architecture and platform for sports car. It led to two different vehicles - BMW Z4 and Toyota Supra. Essentially, the same vehicle under the hood, they remain authentic to their brand identities. Earlier, manufacturers and coalitions built platforms and shared across different models and brands. These platforms were developed over years, as long-term investments to support a wide variety of products. However, the technology, market and customer demands are changing faster these days. Advancements in material science are plateauing, and the architectures are converging. The companies then collaborate at a platform level and compete at product levels.

This is not a phenomenon in car manufacturing alone. One can observe the same in home-appliances, mobile phones, computers, and now in software engineering. A while ago, the shared platform for software was CPU architectures. Soon Linux became a platform at operating system level, branching out into various products (distros). Later Java Virtual Machine (JVM) moved the platform one level higher to application runtime. Many enterprise applications could leverage the common architecture across different implementations of JVMs. Virtual machine was a good abstraction, but failed to become a platform due to dominant players, without a joint architecture. Cloud started as an extension of virtualization, and still remain disjointed. It is still not easy to interoperate the products (virtual machines and images) across the clouds without a migration tool or service. Containerization became a leveler and a shared architecture across different underlying deployment models. And now, Kubernetes has become a platform and a shared runtime architecture for products packaged as containers. There is an unprecedented collaboration among competing companies on containerization and Kubernetes. It is a good time to build and deploy software products.

Yet there is another important trend to consider. As networking layer has become reliable, fast and software-defined it has increased the adoption and reliability of Service-based Architectures. Today, services are the building blocks of an application, more than just an integration layer. These developments, as we abstract away the implementation details, it gives us an opportunity to advance the concept of platform to next levels.

There is an alternating tick-tock pattern between innovation and standardization. We now have a standardized deployment model using containers and services. The next tick is innovation led, by different parties, could end up disjointed. Cloud, DevOps, Data, Low Code, No Code platforms are innovating in various ways, to speed up product development, with little or no standardization. During this phase, enterprises are free to choose or build some of these platform components. It is important to recognize the platform layer in software and product architectures, even if there are few standards. This helps us to design systems where platform concerns are separated from product concerns. And for example, these platform-concerns could be as simple as monitoring, or notifications. Or full-fledged features such as identity management, or payment processing.

This brings to the concept of protocols. As we learned to separate/extract platforms from products, over time we should be able to abstract protocols from platforms. Standard protocols ensure interoperability and compatibility across different implementations of platforms. HTTP is the protocol over the Internet is built, and browser is a platform. It did not matter who served the content, or which browser ran the application. As we moved up one layer, we ended up with different business platforms over HTTP, and take for example e-commerce. We now have a handful of leading e-commerce marketplaces, similar to cloud vendors in technology space. Suppose there are higher-level protocols to manage products, customers, orders, payments, and fulfilment. It would lead to interoperable platforms, across which sellers would compete and differentiate. India’s ONDC is such an open protocol for e-commerce, to create an interoperable ecommerce ecosystem. It would be interesting to see the adoption, how it shapes commerce in general.

When the ecosystem advances into a level-playing field, we move to a higher platform supported by standard protocols. It then opens opportunities for innovative ideas, processes, and business models.