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:
|Bespoke application||Customisation on platform|
|COST, TIME||Requires software development hence high costs, time||On the right platform, an order of magnitude smaller compared to bespoke application.|
|RISK||Uncertainties in quality being poor, cost, and time overruns of the software development undertaking. Often getting all three right has been difficult for most projects.||
Quality can be pre-determined.
Platform quality matures over time.
The extent of requirement fit offered by the platform has to be determined at the start itself, which could be technically challenging.
The roadmap of the platform is determined by the third party. Depending on the platform roadmap too much, could be a double-edged sword. On one hand, you get features for free. On the other, they may take longer to arrive than expected.
|Requirement Match||End solution likely will meet all your requirements.
In control of your destiny for subsequent development, albeit it will continue to require resources.
|Cannot expect a 100% match, but one can aspire and achieve 90-95% in most situations.|
Let us look bit deeper into what this means more specifically for community and field programs. Such programs lack the following 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 present 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.
Author: Vivek Singh
Published On: 04 November 2020