In the last few years, we have suddenly seen a spike in usage of the term software platform. All types of software applications started getting called platform. But the term platform has a specific meaning which differentiates it from technology/software applications. A platform enables other software applications to run on it, mostly to be used by end-users.
In other words, we could say that a platform by itself is useless to the end-users unless it is programmed or customised for specific usage. WordPress, Moodle, Google Forms, ODK, Avni - they are all platforms. Google Docs, MS Paint are not platforms as they are mostly consumed directly by the end-users. Though the ease of customisation can blur the lines between the user and the customiser and the same person may be playing both the roles.
It was important to establish this distinction so that we can answer the more relevant question - how should we decide when to use a platform and when to develop a bespoke software application? Bespoke means custom-made—made based on the specifications of the person ordering it, as in a bespoke suit (from dictionary.com). The diagram below shows two distinct scenarios.
The essential tradeoff between these two options is of cost, time, risk, and requirement match. A list of tradeoff involved are as follows:
Let us look bit deeper into what this means more specifically for community and field programs. Such programs lack these resources:
- Funds available to use for technology deployment
- In-house technical skills to develop such solutions
Hence the best solutions are those which require fewer funds, can be managed with technical skills available within the organisation, while largely satisfying the requirements. With these key parameters of evaluation in mind let us see the matrix below which presents various scenarios and our recommendations.
- Whenever our functional requirements are commonly shared by a large number of people in various disciplines - the widely available consumer platforms can serve such needs.
- When additional features are required that are specific to the domain of work, we have two options. Either use a platform or get the software developed inhouse (via a software development partner). Unless the features required are not present in the platforms available, going for bespoke software development incurs much higher cost - with the same result. Additionally, platforms afford you the ability to perform customisations inhouse as they require much lesser software development skills. Hence you are less dependent on your software partner (for certain customisations one may still require software vendor's help, but with good platforms, they are less and keep getting lesser over time).
- When one finds oneself in a situation where only very few functionalities required are missing the platform - which is quite often the case. One can choose the bespoke application route or use the platform without the missing functionality. We have observed that there is an additional route available with open source platforms where one of the following may work out.
- You may check the feature's availability in the product roadmap of the platform. Open source products share their roadmap publicly.
- You should connect via community route and work out a mechanism to add the functionality to the product roadmap or even get it done by paying a small amount (which may be still much lesser than developing bespoke application).
ps: Lastly, the question mark space may be of academic interest to some. Why such a blank space exists? As we understand, it is difficult for platforms to move up the feature ladder without moving right in customisation complexity as well (and vice-versa). Hence, where a platform places itself is a strategic tradeoff made by the organisation/people behind the platform. Overall one should always expect the blank space.
Icon credits: icons8
This article has been republished with permission from Samanvay Foundation. View the original here.