Software Architecture - NFR - Portability
In continuation of the Non Functional Requirement blog series, today, I am talking about the value of portability.
Portability is one of the important NFR which is often ignored. One of the prime reason for it not getting the required value is because, its absence does not create an immediate or even a mid term impact.
Before we dive in, let us understand what Portability means.
Software portability attributes to that quality of the application which enables:
Transferring of the software from one Operating System to the other without making changes to the code or architecture.
Reinstalling a program from distribution files on another computer of same architecture. Processor of 32 bit or 64 bit and so on.
Building executable programs for different platforms from the same source code; this is what is usually understood by "porting". This promotes reusability (another NFR).
We may have different installation procedures for different operating systems but the source code will remain the same.
There can be some configurational differences but it does not result inhaling different code base for different platform.
The other nomenclature for portability is, cross-platform software (also multi-platform software or platform-independent software). It is computer software that is implemented on multiple computing platforms.
For example, a cross-platform application may run on Microsoft Windows, Linux, and macOS OR iOS or Android Cross-platform programs may run on as many as all existing platforms, or on as few as two platforms.
Also, keep in mind that portability refers to the ability of an application to move across environments, not just across platforms.
So, why is portability important? - In today's world where the software application owners wants to provide an extensible and wide range of working platforms, it is important that software should support wide range of platforms and environments (on which it can operate).
Whether the software you are developing is a web application OR think client OR mobile app, you will have to install or host it. A think client / mobile application will be installed on the OS while a web application needs to be hosted on web / application server.
Depending on the platform one uses to develop the application binds to the underlying platform (OS). And given, we would want our users to remain loosely coupled from the underlying OS, we would want the application to support the portability.
Imagine, a web application that is developed in MS .Net that can run only on Windows based IIS or OS, you are limiting the options for the consumer to make it host / run only on Windows.
This forced affinity limits them from being in a more competitive. If I have the option of running my web application on Linux or Windows, then the decision to run is going to be based on commercial viability and other platform advantages I can get. And it is not on where it can run.
Also, the application is not locked to a particular architecture and OS. One can port if your deployment and maintenance strategy changes. You are not compelled to change the source code for it.
Further we all know that cloud computing is the future. It would be nice for you to move your application from Azure to AWS to GCP depending on your ever changing goals and commercial viability parameters.
Further for mobile apps, developing different apps for different OS can be avoided if the same is developed using a code that can port between iOS and Android with minimum configuration and installation changes.
And when should one worry about portability? Is it mandatory to make the software a portable one? If I have to answer this question in Yes or No, then the answer is No. It is not a mandatory attribute (unlike other NFR like security, performance, etc.).
So when does the software have to be portable? Following scenarios will address this question.
If the application is supposed to run across client's infrastructure (client hosted or installed) and your client base is spread across different OS / Platforms then better to go for portable solution. This will (1) enable you to tap more customers (2) reduce the maintenance of multiple source code for each platform.
If the application is to support open source platforms, it will be better to make the software portable.
You are developing a mobile app that relies on API for serving the business logic; developing a cross platform app from the same code would be better than developing native app that has different code for different platform.
You want portability for the web application to run on Windows or Linux and hence ability to move across different cloud service providers and ability to run on various PaaS platforms (Azure functions or AWS Lambda functions) then having a portable solution is better.
However, you are super sure that your client base runs only Windows, then you may keep the design portable but actual development may have affinity towards the given OS. But if you have slightest doubt with the above assumption, better to stay platform agnostic by developing using the portable options.
If you are running a SaaS offering and customers have no say in where you host your application, then you are free to choose the platform for development. In this situation, portability is good to have but may not be a mandatory NFR.