Platform vs. Stairform
It’s probably fair to say anyone working in software knows a term called platform. It’s a term borrowed from transportation industry, where a raised and flat space on which passengers trains in a station. In software, it means something you can leverage, either an environment for running your software or a development library for building your applications.
Like many things in software, platform has never had a clear definition. Different people basically have their own versions of definitions. That is not necessarily a bad thing – at least it helped create a buzzword. Of course it’s a problem for communication.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
Here, I would like to nail it down to software development. In this context, the platform means a set of APIs that provide services for you to build applications in shorter time with less effort. The APIs can be packaged as static or dynamic libraries, served locally or remotely. For a reasonably complex system, you will need different APIs for data services, transaction services, messaging services, etc.
The term platform implies that it’s flat, mostly with one level of abstraction. While designing APIs, I find this is not enough for increasingly complicated requirements in software today. Instead of a flat abstraction, we need multiple levels of abstractions, which is more like a stairway than a platform. That is why I use a new term called stairform.
Why is stairform more attractive than platform?
First of all, it offers multiple levels of abstractions. The developers just pick the right level of abstractions best for their applications. High level abstractions are generally better than lower level ones. But it’s not always true. You would be surprised to find a developer insisting to use stub or even HTTP protocol when there is an object layer for managing vSphere.
Secondly, it exposes all the levels. Being a platform means you hide everything underneath the surface. It’s not true for a stairform. Whenever needed, you should be able to go one step down.
Thirdly, it has distinct levels of abstractions. When multiple levels of abstractions are mixed together, it simply increases complexity and hurts usability. It’s already complex enough for one level of abstraction. Why bother to complicate it more? Dividing them into distinct layers definitely reduce the complexity of each layer, therefore good for users.
Too much abstract discussion? Let’s take a look at the open source vijava API. It has three layers of abstractions: OO layer which I recommend all the time; stub layer which consists of procedures that most developers should avoid; and HTTP layer which works on the XML messages that almost every developer should keep away from. While most people use the OO layer, they can also access the underlying two layers when really needed.
I don’t expect stairform to become another buzzword, but do encourage layered APIs and other forms of software in your projects.