Modern software applications have learnt to depend on the usage of multiple components as a part of their architecture and design. These components can be used for different functionality, typically specialized functionality that is either difficult for the developers of the product to write, or impossible because of some technological constraints (for example, for working with several video formats, the most feasible way is to use components provided by 3rd parties because they have the technology to read the codecs used and allow the product to work with these video formats).
When you consider the case of products that go through several versions, the components that they use may be the same across versions, and the component may follow a schedule that is different from that of the product. Hence it is even possible that 2 different versions of the product follow the same component; conversely, you would have the case where there are multiple versions of the components that are available, and for business reasons, it makes sense to allow only specific versions of the product to work with a specific component. Consider the following case:
Product released version 5 in 2012 and version 6 in 2013
The component used was version 2 in 2012 and version 3 in 2013
In many cases, the newer release of the component may contain some important new functionality for which the organization would want the users to upgrade to version 6 of the product and would not want the user to be able to take the version 3 of the component and use it in version 5 of the product. This may seem odd, but it makes perfect business sense to follow such a strategy to also drive sales of the newer version of the product.
Given the continuity of the software cycle and the need to avoid making unnecessary changes in software, the easiest way of implementing such a functionality is by asking the product to pass on the version number (along with other parameters which would be required for the smooth integration of the product and the component); there would be code in the component which will check for the version number of the product and work accordingly. This in my opinion is one of the most elegant ways of implementing these kind of checks; the advantage of such a system is that it also supports a system whereby the same component can display different functionality based on the product version where it is being used. So, you could be having a trial version of the product, which passed on the parameter related to the trial nature of the product, and this ensures that the component behaves in a different manner (for example, reading such a parameter could ensure that the component allows the user to view the video file but not make any changes in it, while somebody who has the paid version of the product could both read the video file and also make changes in it - and all this can be done through the same component).
When you consider the case of products that go through several versions, the components that they use may be the same across versions, and the component may follow a schedule that is different from that of the product. Hence it is even possible that 2 different versions of the product follow the same component; conversely, you would have the case where there are multiple versions of the components that are available, and for business reasons, it makes sense to allow only specific versions of the product to work with a specific component. Consider the following case:
Product released version 5 in 2012 and version 6 in 2013
The component used was version 2 in 2012 and version 3 in 2013
In many cases, the newer release of the component may contain some important new functionality for which the organization would want the users to upgrade to version 6 of the product and would not want the user to be able to take the version 3 of the component and use it in version 5 of the product. This may seem odd, but it makes perfect business sense to follow such a strategy to also drive sales of the newer version of the product.
Given the continuity of the software cycle and the need to avoid making unnecessary changes in software, the easiest way of implementing such a functionality is by asking the product to pass on the version number (along with other parameters which would be required for the smooth integration of the product and the component); there would be code in the component which will check for the version number of the product and work accordingly. This in my opinion is one of the most elegant ways of implementing these kind of checks; the advantage of such a system is that it also supports a system whereby the same component can display different functionality based on the product version where it is being used. So, you could be having a trial version of the product, which passed on the parameter related to the trial nature of the product, and this ensures that the component behaves in a different manner (for example, reading such a parameter could ensure that the component allows the user to view the video file but not make any changes in it, while somebody who has the paid version of the product could both read the video file and also make changes in it - and all this can be done through the same component).
No comments:
Post a Comment