Platform technologies are systems build upon a platform architecture that distributes the system out into different levels of abstraction. This is done in order to differentiate between core – platform – functions, and the application layer that sits on top of, and draws upon, these underlying common services.1
During the past few decades, with the rise of the Internet platforms, such as the App Store or eBay, have proven to be some of the most dynamic, innovative, and fastest growing services. But of course, the platform model to systems architecture has always been there since the invention of farms and factories to the making of Lego building blocks. When many people see a new technology at work, they don’t usually consider all the pieces that went into its creation. They simply see the amazing capabilities and never give it much thought. However, within advanced industrial economies, many products and services are enabled by the power of abstraction. They are remixes, built out of services from platforms that enable the endless bundling and re-bundling of different components. Wikipedia defines a platform technology as a structure or technology from which various products can emerge without the expense of a new process introduction. In order to achieve this, our system needs to be architected to have two fundamentally different levels, that is, it must have a platform providing the basic services that can be combined into different configurations on the application level to deliver various instances of the technology to the end-user.
An example of a non-platform technology is a hammer, for it is a homogeneous system. There is no differentiation between the system’s infrastructure and its application. They are all just one thing. It is an instance of a hammer. It cannot generate new and different configurations of itself. The same can be said of a car. It is an instance of a technology. The end-user gets and uses the whole thing. To make the comparison clearer, we could compare the instance of a car with an automobile platform that allows a motor company to release several vehicles built upon a common chassis, which is the platform, with different engines, interiors and form factors, for the same or different vehicles and brands within the company.
Probably the clearest and best example of platform technologies are personal computers. The platform, in this case, is the computer’s operating system. But before we can get to the platform that’s doing all the great work, we need a foundation for it to sit on, that is, a set of enabling technologies. In this case, our foundation layer is our computer hardware and all the low-level firmware that interfaces between it and the operating system. But within a business, our foundation layer might be the economic system it is a part of, the public services such as security, rule of law and maintenance of natural resources that would enable our business to function. The same would be true of a city. It rests upon and is enabled by a national infrastructure system.
The next layer up from the foundations or hardware is the platform itself, the computer’s operating system in this case. It essentially manages the computer’s resources and services that will be required by applications. The platform takes the resources available to it from the infrastructure and creates the Lego blocks that we will be used to build things with. These resources are presented to producers on the application level through APIs, or application program interfaces. In an automotive factory, the platform would be the physical technologies in the production line for creating the car’s parts. Our employees can rearrange this production line to create different vehicles. In the example of a city, this platform level might be the urban utilities that contractors will interface with to build offices and residential spaces, and there will be a standard set of procedures for them to do this. On top of the operating system lies the application layer. Developers draw on the services provided by the operating system and bundle them in various different combinations to deliver a finished application to the end-user. Apps in the App Store, the cars coming off of our production line, the buildings in a city or the financial products offered by a bank are examples of the application layer, endless configurations, and reconfigurations in response to the perceived needs and feedback of the end-user.
Lastly, the user interface layer. When the end-user switches on their computer, they don’t want to see 0’s and 1’s or lines of code. They want to see things they understand, pictures of files, and nice drop down menus. The majority of people who interface with the systems we are architecting will do so, so as to get the maximum functionality out with the minimum input of effort. In order for them to do this, we need a layer that translates the internal logic of the system into a language they understand. This interface might be the dashboard on our car or the receptionist in our hospital telling people where to go. Whatever it is, it is all about the end-user, the language they speak, what they need, and how to translate the systems functionality into a solution that involves the participation of the end-user.
In continuing with our analogy from the world of I.T. we might call this a solution stack, the full set of subsystems and layers of abstraction to provide the platforms full functionality without dependencies. An important thing to note is that as we go up each level of abstraction towards the end-user, we are simplifying the complexity and level of engagement required. Those working on the platform level require a deep understanding of the system and have to deal with its full complexity but are relatively unconstrained. Those who engage with the system on the application and user level are constrained by what the platform providers have designed, but being enabled by this technology they will be able to do more with less input and engagement. The net result is that we should get an amplification effect as we go up the solution stack due to the increased ease of engagement. Thus, there will be many more application developers than there are operation systems developers, and there will, in turn, be many more end-users than there are application developers, and this should be the case wherever we are using this platform model to systems architecture.
Finally, we might ask – why should we care about platform technologies? There are a number of reasons this architecture should be of benefit to us. Firstly, by distributing the system across multiple layers, we can abstract away the complexity that users or producers of the service have to deal with. Everything gets its own space. Secondly, we can avoid redundancies by having the platform provide the common services required by all components. We can reduce the need for each component on the application layer to re-invent the wheel. Thirdly, platforms are the ideal architecture for creating user-generated systems. Thus, we can leverage the amplification effect we discussed earlier to do more with less, helping to maintain an agile core system. And lastly, the platform architecture is ideal for building flexible, adaptive, and evolutionary systems. Given its independence from fixed instances, the system can stay innovating on the application level to continue regenerating itself.