Commercially available off-the-shelf' software from a non-standard developer is not subjected to rigorous tests and certifications and may not be able to integrate with all systems, cautions Dr R Srinivasan

THE next topic that we will see in this series will be on Technology AntiPattern. While it is important for a software development organisation to move along with technology, considerable thought needs to be given to decide whether a new technology is really needed for implementation of the projects on hand. If the answer is yes, the next question is whether the team has the required expertise to absorb the new technology. It is customary that the decision on whether to adopt a new technology is taken by the architect supported for implementation by the designer. If there is a lack of understanding of the new technology, these two will make wrong assumptions both in the architecture as well as in implementation. The people likely to suffer because of this will be the project manager and the team members.

Since the technology is new and the architectural design is not very clear, it is possible that mistakes are committed, both in effort estimation and schedule estimation. The ultimate result will be inordinate delays and there will be chaos in the implementation of the projects. Even if the team manages to carry out the project to a certain level, the question will be whether the software is stable under different operating conditions. All this will occur because of the hope and assumption that the product developed based on the new technology will have a long and good future in terms of business. We will discuss some of the technology antipatterns that occur in the software development scenario.

One of the criteria followed by some organisations is to investigate whether ready-made commercially available components or software is available in the market, so that it could be bought and integrated as part of a project in software development. Of course this idea is good and that is what is the name of the game today. This is called reusability of a well-developed software component leading to the concept of "plug and play". However what really happens is, in order to meet the deadline, we tend to buy readily available software, called as Commercially Available Off-the-shelf (COTS) software. The risk is we may have to face the situation wherein the software could be from a non-standard developer who might not have subjected it to rigorous tests and certifications. Moreover, we should examine whether it can be integrated with our system so that there is no problem in interoperability with other modules. The antipattern that arises due to this is called as the "Battery Not Included". William Brown says, "Unreliable COTS vendors can cause users to struggle with version management of erratically evolving software and the embedded costs of the continued inclusion of these COTS in new applications or products." What we mean by this is that once it is discovered that we may end up with a poorly designed COTS, it may lead us to replace it with more stable COTS software.

Battery Not Included AntiPattern may happen because of one or both types of COTS, classified as "development time" COTS and "embedded run time" COTS. To cite some examples, those at the time of development will include the selection of tools in the programming environment or the present day demand in middleware technology and even selection of code generators. Under the run-time mode, we may end up getting the bridges and gateways needed for integrating with other modules in the system or even the ready-made software packages in the domains of finance and accounting. The problems faced by the developers, due to the selection of a wrong COTS, will be aggravated if the vendor keeps changing the versions very frequently, thereby continuously redoing whatever has been done so far-a situation leading to frustration among the developers. A similar situation may happen due to an embedded COTS, which was procured without completely analysing its capability to integrate it with the rest of the system developed by the project team.

In today's scenario there are a large number of COTS vendors in different areas of applications and tools and it is a competitive market. If the architect of the system is not completely aware of the drawback of the COTS he is suggesting, his architecture based on which the development takes place will be weak and brittle. Experts like Douglas Bennett clarify that strong architectural process has to be followed to match the commercially available off-the-shelf software with the functional and data requirement in a software development project. He suggests in his book, Designing Hard Software: The Essential Tasks, that we have to take care of four important tasks to match the COTS, namely, external requirements, system state, behaviour identification and to decide software system architecture. SEI also gives a set of rules to follow COTS-based- system approach called CBS encompassing Identification, Qualification, Adaptation, Integration and Upgradation of the system employing the proposed COTS.

  ( To be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)