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.

1. 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.

2. If the application is to support open source platforms, it will be better to make the software portable.

3. 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.

4. 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.

5. 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.

6. 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.

How can one achieve the portability? If you have made a decision to have your application adhere to the portability NFR, then the next question would be how to get there.

One can develop portable application by making sure that during the development life cycle, one does not use any libraries or components that are OS specific. For e.g. using Win32 / 64 COM components will make your application run only on Windows. Using the native features of iOS will make your app locked with the iOS platform.

Some of the options to leverage to make the application portable are:

1. Using .Net core instead of .Net Framework.

2. Using Java portable libraries that supports Win and Linux

3. Using hybrid platform development options (e.g. React Native) for mobile app development (so that it works on iOS & Android using same source code)

4. You may also want to refer http://carlcheo.com/portable-app-creators for exploring various portable app creation options.

5. Use of cross platform programming stack (e.g. Angular, PHP, Python, Mongo DB, My SQL, etc.) which can be deployed across different app / web servers (e.g. Apache, Tomcat or IIS) that supports different OS.

The above article only scratches the surface of the "Portability" NFR. There's much more to it, however, I felt that keeping the article at this level will give enough insights into this NFR and can provide the platform to perform a deep dive if need be.

Please share your feedback and observations for this article. And if you feel, there's something missing or should be addressed, please feel free to let me know and can do so.