Building a "Platform"?

Anand Kumar Keshavan ( Founder/Partner- SwanSpeed Consulting)

In recent times, many of our clients have expressed interest in building platforms. But what is a “platform” exactly? How is it different from your regular business applications? What are the challenges that one is likely to face when one attempts to build platforms?

We note that this wish to build platforms often overlooks the challenges and possibilities of business success. We have to recognise these challenges to be mentally prepared to take up such an endeavour.

So, for most of us, our common day to day experience conditions us to develop applications, and this deflects our attention aways from the crucial aspects in building a successful platform.

Before answering these questions let us look at software in general. One may tend to view all software as similar. What is there after all? Write some code, test it, and roll out , right? In reality “software” comes in vastly varying classes of behaviours. For example, one could define a simple business application ( such as a leave application app for a small business) in terms of a set of fixed behaviours. On the other extreme, we have compilers, operating systems, etc, which define wide classes of behaviour. “A platform” , falls somewhere between these two extremes. While creating or evaluating the general architecture of large software projects, it is important to understand the differences between types of software based on some properties such as the configurability of their behaviour or classes of behaviour. Why? Because, depending on the class to which our software belongs to, we need to fine tune our techniques of defining, developing, testing and deploying software.

(Traditionally, OSs and other infrastructure were considered as platforms- as they allowed other software to run in their context. In the past few years, this definition has been expanded to include many SAAS systems that allow massive behavioural range and allow other DSL programs to run in their environments).

Let us take an example to explore more about the nature of various classes of software.

Imagine a small business that has built and leave application software for its own use. The application basically allows a user to apply for 2 types of leave ( say, PTO, Sick). The business also has rules for how leave is accrued or accumulated for an employee. Let us say, PTO accrues at the rate of 1 per month with a maximum of 12 in a year. Every employee is entitled to 6 days of sick leave every year. This is credited to the employee’s account during the 1st day the year. The small business creates an application which handles all this and it is generally working fine. Any changes to these rules are directly coded into the application as and when they are changed. The important point to note is that this application exhibits a fixed behaviour for a given type of user.

Now let us say, this company implements this solution and finds it to be great success and hence they decide to spin off this application as a separate business, so that it can sell this software to other companies. When they explore this idea, they find that hardly any other potential client has exactly the same types of leave and corresponding rules, and manner of accumulating them and so on. Remember any change to rules of types of leave require the code to modified, tested and released. Since they can’t do this for every new client, the developers in the company decided to create a set up module wherein:

(a) the different types of leave are defined by the user ( a user with special permissions).

(b) rules of accumulation are also allowed to be fine tuned by configuration. For example, the user during set-up can specify how sick leaves get credited-- end of every month, end of every quarter, or beginning of the year etc.

(c) a workflow for approval of leaves. (Manager approves, for leaves greater than three days, Manager’s manager also needs to approve etc.)

At this point the the company has started taking baby steps towards a “platform”. The behaviour is not fixed anymore- it is subject to the values that have been set up during the configuration. Some of the workflows can be partially configured. The approval workflow also can be configured using some parameters.

[Exercise: please try to write use cases in the Given/When/Then format and create a set of test cases to see whether different types of configurations of this version of software work as per spec- remember the behaviour of the software varies according the configuration setup by the user]

Let us assume that they do all this and they get reasonable success. But they figure out that many companies cannot use their product because of limitations of the configurator they have created in the setup module. Many companies may want other features and special types of leave-- for example, compensatory off for working during the weekend, with rules of accumulation and workflow for approval. It is not possible for the creator of the software to modify and customise the software for every new customer. They go ahead and create a way compensatory offs are computed by marking Saturdays and Sundays a weekly offs.

But when they release this version of the product, they realise that different countries have different weekly offs and holiday list. To solve this they create a configurable calendar for each client. Just as they release all these they get an enquiry from a big multinational continuous process chemicals company. Now the weekly offs, holiday list and compensatory offs have to be modified by location and by employee ( each employee has his own calendar for weekly offs as these are 24x7 ops).

[Exercise: create a user story for managing weekly offs/compensatory off of a multinational continuous process organisation with vary rules for overtime computations in different countries]




Now this is when they move towards a more advanced platform- where you can create approval workflows, rules etc using a Domain Specific Language ( DSL) that they will provide. The user will have to get a trained power user who can program using this DSL. Now this is a long way off from the original and its behaviour is not longer constant-- the software potentially has infinite set of behaviours. Now it is moving towards a true platform such Salesforce or SAP. As this concept develops the company might even have to set up an implementation team who can configure the software based on the behaviours desired by a client, using the DSL if required.

[ Exercise: specify the requirements for the DSL and define its semantics. Also come up with a set of test cases to ensure that the platform’s behaviour gets modified as specified by its configuration and DSL scripts created by the implementation partner-- hint: it may take the life of the universe to list and execute all possible behaviours of the software].

In general terms, we can confidently say that as the “configurability” of software increases, the harder it gets to specify and test the software. If one tries to test the software as if it is fixed application ( the original one) one will end up with hardly any behavioural coverage.

As one moves towards a platform one needs think at higher levels of abstraction. This goes not only for developers, but for the people who define the requirements. In some cases, the BA guys may even have to learn formal specification techniques ( TLA+, for example) as well. Platforms do not always evolve in an orderly manner. Fixed behaviour applications are difficult to transform into platforms- especially when there are existing users. Successively evolving from a fixed behaviour to generic behaviour while the software is being used by many users can be as hard as changing a tyre in a moving car!!

A platform supports applications, usually a number of them hadn’t even been thought of at the time of making the platform. Since the generality of a platform is substantially wider than of an average application, its definition, design and testing are of a different nature.

If you are planning to build a platform, please keep in mind that the techniques used for specifying, developing and testing have to change from the way such activities done for a fixed behaviour application. Applying the techniques that have worked for fixed behaviours apps ( even those that have been roaring successes in the past) to the development of a platform only leads to frustration. This also applies to people. People who have successfully developed fixed behaviour applications, even those who have been “stars” in their organisation, start floundering. It is as if the thought processes, that worked so well for them in the past , seem to have hit a brick wall.



The following diagram may help the reader in understanding the differences between different classes of software.




As you go up this level, you must develop the appropriate engineering process that can deliver “platforms”.




The author is founder/partner of SwanSpeed Consulting. SwanSpeed helps companies to architect, build, test and roll-out highly scalable/reliable/maintainable software platforms. If your “platform” program is in trouble, or if you are planning a platform from scratch, do reach out to me. SwanSpeed can show the way!!