Framework vs. Platform What’s the Difference?

I am a confessing pedant. Despite my personal failures in this regard, I believe deeply that correct usage of language provides significant added value. To quote the aphorism from Mark Twain:

“The difference between the almost right word and the right word is really a large matter. ’tis the difference between the lightning bug and the lightning.”

With this in mind, it may make sense that I find the lack of clarity surrounding the two concepts of framework and platform extremely irritating at times. Every company in the world that has anything to do with development has a platform. The open source world is full of frameworks. But when asked, very few people are able to define these concepts. Is it possible to claim full understanding of the subject of a conversation when I am not able to provide clear definitions for basic terminology?

I would like to propose one possible definition using an analogy.

A platform is something which can be closely compared to the box of building blocks which my children had in their room when they were small. The individual blocks are the components. In an ideal platform, these components can be assembled in many different combinations, creating a broad range of final products. This is why platforms are hot stuff, they offer the holy grail of software re-use.

But what are the pre-requisites for building a platform? A successful platform will have several technical requirements that must be satisfied, this is the task of the framework.

Let’s start by asking where the definition of component structure came from? Going back to the comparison with building blocks, a limited number of possible shapes will be used. Which shapes make sense will depend on the guiding principles which were chosen at the outset. The underlying philosophy of the framework will dictate the range of possible component structures. BTW, “component” is another one of those concepts which is often used, rarely thought through and usually poorly defined. However, the simple analogy which is being used makes it immediately clear that a well-defined component concept is essential.

The next question to ask is how the components are assembled. Is a connector technology used and how does it work? Of course, our components might be similar to wooden building blocks with no real connectors between blocks. This isn’t good enough for a platform. Lego(tm) and Fischer-Price(tm) show two alternatives. Both of these add connection points (aka ports) to every building block, allowing other blocks to be attached. Ideally, this is the way that the components in our platform should also work.

A final key observation is that an individual building block has no knowledge of the internal implementation or properties of any other building block. It only has its attachment points (ports) and the assurance of knowing that it can work together with any other component as long as the connector (the interface) matches. In a very real sense, the components are mutually anonymous. Note that this is very similar to the principal of mutual oblivion advanced by Ralf Westphal.

A framework can now be defined as a set of concepts, libraries, tools and practices which provide:

  1. a standardized component concept to be used within the platform
  2. a standardized connector technology which
      • enables communication between components in the platform and
      • preserves anonymity of individual components

A platform is a collection of re-usable components which have been constructed in compliance with the principles and philosophy of the framework.

Other definitions are possible, but I find these definitions extremely useful.

Please also notice how fundamental the concept of standardization is in this context. Think for a moment of a world in which every electrical plug were a hand-crafted, unique product. Mass produced electrical devices would never become an industry in such a world. The same holds true for a platform. All platform components must have a standardized structure and must use standardized concepts for communication to ensure that they are able to play together.

I have explained my view, that a platform requires a framework as its foundation. The framework provides component and communication paradigms. It provides the standardization which is essential to be able to make interchangeable components. As components are designed, built and tested they become building blocks that contribute to the platform. The framework restricts the degrees of freedom that developers may exercise. It channels and guides their efforts to achieve that critical degree of standardization that is required for the success of the platform.

The framework can have additional responsibilities as well. Ideally it will support a concept of causal chains (German: Wirkketten), allowing run-time dependencies, data flows and control flows to be identified. Furthermore, it should contain (and hide) the needed machinery to deal with concurrency. But that will be material for another article.