When a management adopts 'Vendor Lock-in' antipattern, they virtually fall into the dictates of the vendor product, thereby having no control over its technological aspects, writes
Dr R Srinivasan

We will next look at a very critical antipattern encountered in some organisations, particularly start-up software development companies. Normally customers give a small project to such an organisation as a pilot project and based upon its success future relationships continue. Under this circumstance the project management committee may feel that if they design the architecture of this software, based on easily accessible software packages from vendors, they will be able to complete the project on time. But, unfortunately the outcome of this so-called success may lead to a situation wherein they may get into the habit of repeatedly using the commercially available packages from the vendor and decide the architecture accordingly.

This means that the software projects adopt a product technology from the market and become a victim to depend upon the vendor's implementation. What will be the after effect of this? For example, we may come across developers who say that when they try to read the new data files into the old version of the application, the system crashes, or when the data is read into the application it is not possible to get it out again. This may also lead to a false diagnosis that the system has a virus. This antipattern is rare in established organisations, and is called 'Vendor Lock-in'.

William Brown, et al, also called it 'Product-dependent architecture', 'Bondage and Submission' or 'Connector Conspiracy'. Even if this adoption works in the initial design, problems will start emerging in the future with respect to upgrades, interoperability with other software systems and above all maintenance of such systems. Because of the dependence on the vendor software as the main element in the design, any delay due to the vendor supply will result in unexpected and undesired schedule delay, cost escalation and above all a disgruntled customer. It would be worst if the expected software from the vendor is never delivered due to internal problems at the vendor's end. Looking at the over dependence of the organisation on his product, it may even lead to a situation when the vendor will ask for changing or renewing the product license, frequently saying that he has come up with a new version.

The obvious question is: why does an organisation get into such a situation. The reasons may be many, but Brown identifies five among them:

1. The vendor's product may be a deviation from what it has been published and informed to the software development group.
2. The product selection did not go through a good technical analysis to access the suitability.
3. Too much belief and faith on the marketing aspects adopted by the vendor.
4. Lacking thorough knowledge for implanting the product as part of the application.
5. Failure to manage the complexity of the product because it exceeds that of the needed application.
   

As we did in the case of other antipatterns, let us discuss the refactored solution for the Vendor Lock-in. The system architecture should be in the form of layers, such that there is a layer between the system's application software and the vendor software. This intermediate layer is called the 'Isolation Layer'. Experts suggest that such a layer will provide software portability from platform specific interfaces. However, it should be borne in mind that such a solution is feasible only if,

1. There is a possibility of isolation of application software from other sections of the system such as the middleware, the operating system and security aspects incorporated as part of development.
2. The designers anticipate changes to the underlying layers within the lifecycle of the affected software.
3. Multiple infrastructures to be supported during the life cycle.
   

As suggested by Dr Mowbray in CORBA Design Patterns, it is necessary to install gateways between multiple infrastructures which have to be supported concurrently. In a nutshell, the refactored solution dictates the creation of the isolation layer that abstracts the underlying infrastructure or vendor-dependent software interfaces. Dr Mowbray also illustrates with the 'Object Wrapper Pattern', providing isolation to and from a single object infrastructure.

Quite naturally the curse of Vendor Lock-in will affect both the management as well as the developers in the organisation. The management will realise that they did not have control in deciding the technological aspects and thereby falling into the dictates of the vendor product releases repeatedly. As far as developers are concerned, they should not only inculcate a sound knowledge of the vendor's products but should also be on the continuous learning curve, if the vendor comes up with frequent new releases making the earlier one obsolete.

( To be continued)

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