Continuing the case for Open Systems Computing (OSC), and since we discussed Interoperability in the first blog post, we will focus on Portability today.
Reiterating the definition we are using for OSC, it may be defined as those computer systems offering: 1) interoperability, 2) portability, and 3) open software standards.
Portability, similar to interoperability, usually refers to how well “new” software products work with “existing,” or “legacy,” software and/or systems in a corporate environment. Which begs the question: what does it mean to “work well” within the corporate environment? Precisely this, almost any software product can be made to work with any other software or hardware product (I understand this is a bit of a stretch, but bear with me). The heart of determining a high level of portability versus a low level of portability for a software product is how much modification is necessary to either the “new” software being interjected into the existing corporate environment or the “legacy” software, which is already operational in the environment, to make them work well together and function properly. If no, or very little development is needed to integrate the “new” software with the “existing” software and/or system, then you are assured the “new” software can be termed to be highly portable. If an extensive re-work of either the existing software or the new software is needed, then the “new” software could be termed to be less portable but only if the fault lies with the “new” software. Let me explain.
The term portability, by definition, embodies the juncture of both “existing” and “new” software being introduced into the corporate environment. However, while it is true that if “new” software integrated with ease into the existing infrastructure can be termed highly portable, the reverse is not necessarily true. The level of ease of integration is not only dependent upon the portability of the “new” software product, but also the openness and non-proprietary nature of the corporate environment as it exists prior to the introduction of the “new” software. In other words, if you have a completely closed proprietary system and you are introducing “new” software into it, the integration of the two will only work with significant modification to the “legacy” system, e.g. perhaps emulation software. It would be very unfair to tag the “new” software as less portable. In this instance the culprit is not necessarily the “new” software, it is the corporate environment built upon non-standard protocols and non-standard APIs.
As we continue on our journey of OSC, my next post will address the third interdependent leg: Open Software Standards. Stay tuned and thanks again for joining us.