AntiPattern Name: Vendor Lock-In
Also Known As: Product-Dependent Architecture, Bondage & Submission, Pottersville
Most Frequent Scale: System
Refactored Solution Name: Isolation Layer
Refactored Solution Type: Software
Root Causes: Sloth, Apathy, Pride/Ignorance (Gullibility)
Unbalanced Forces: Management of Technology Transfer, Management of Change
We have often encountered software projects that claim their architecture is based upon a particular vendor or product line, for example, they make statements such as:
"Our architecture is the vendor's database."
"Our architecture is CORBA."
Other anecdotal evidence occurs around the time of product upgrades and new application installations:
"When I try to read the new data files into the old version of the application, it crashes my system"
"Once you read data into the new application, you can never get it out again"
"The old software acts like it has a virus, but its probably just the new application data."
"Safe upon solid rock the ugly house stands: Come and see my shining palace built upon the sand!
-- Edna St. Vincent Millay
A worst case scenario of this AntiPattern would occur if your data and software licenses were completely allocated to on-line services, and one day, a modal dialog box popped up as follows:
A situation in your future under vendor lock-in.
The name Pottersville comes from the popular film "Its a Wonderful Life." In the film, there are two alternative realities presented. In one reality, the city is controlled by a miserly banker who refuses to give people control over their own lives and property. This results in a culture of violence, hatred, and envy between citizens.
A software project adopts a product technology and becomes completely dependent upon the vendors implementation. When upgrades occur, software changes and interoperability problems occur. Continuous maintenance, based upon product upgrades, is required to keep the system running. Expected new product features are often delayed; causing schedule slips and inability to complete desired application software features.
Symptoms and Consequences
The Vendor-Lock-In AntiPattern is acceptable when a single vendor's code makes up the majority of code needed in an application.
This solution is called Isolation Layer. An Isolation Layer provides separation from other software packages and technology. It can be used to provide software portability from underlying middleware and platform-specific interfaces.
This solution is applicable when one or more of the following conditions apply:
The isolation layer separates application software from product-dependent interfaces which may change.
The solution entails creating a layer of software that abstracts the underlying infrastructure or product-dependent software interfaces. This layer provides an application interface which completely isolates the application software from the underlying interfaces. The application interface should provide a convenient language-specific interface to desired capabilities. The layering software should provide default handling of some infrastructure calls and parameters, but exposes other details when appropriate.
Utilize this isolation layer across multiple system development projects to assure interoperability, consistency, and isolation. Migrate the isolation to new infrastructures as necessary. Also update the isolation layer when the infrastructure is updated. In all cases, maintain the same application software interface, regardless of infrastructure changes.
Provide gateways between multiple infrastructures which must be supported concurrently. See Gateway pattern [Malveau 97]. Provide forward and reverse gateways during infrastructure migration. [Brodie 95]
The benefits of this solution include:
The other consequences of this solution include:
This solution is often used at the global level in commercial products and technologies . Typically the Isolation Layer enables the vendor to provide a convenient language-specific interface to a lower-level technology. Some convenience can be provided through default handling of lower-level interfaces which are more flexible than necessary for most applications.
For example, the HP Object-Oriented Distributed Computing Environment (OO DCE) product comprises an isolation layer. The product presents C++-interface to application developers. Underlying this interface is an isolation layer of software that is built upon the C-language DCE environment. Calls to the C++ APIs can invoke several underlying DCE procedure calls. In particular, just two calls are needed to initialize OO DCE security service interfaces. The underlying isolation layer, in turn, makes over 50 calls to DCE APIs in order to achieve this initialization with the legacy DCE security service.
The Isolation Layer solution is most applicable at the enterprise level. However, individual systems have applied this solution in order to provide middleware isolation. For example, the Paragon Electronic Light Table (ELT) product uses an isolation layer above the Common Desktop Environment (CDE) middleware infrastructure, called ToolTalk. By providing ToolTalk isolation, Paragon may easily migrate their product to a CORBA infrastructure and support both CORBA and ToolTalk infrastructures.
The following examples are three known uses of the Isolation Layer solution.
This pattern is related to the Object Wrapper pattern [Malveau 97]. The object wrapper pattern provides isolation to and from a single application to a single object infrastructure. The Isolation Layer pattern provides insulation of multiple applications from multiple infrastructures.
This pattern is related to the Profile pattern [Malveau 97]. An Isolation Layer can be viewed as a particular enterprise profile for the use of middleware.
The Isolation Layer can be thought of as one the layers in a layered architecture. [Malveau 97] In contrast to most layers, this is a very thin layer that does not contain application objects. Typically, an isolation layer only serves as a proxy for integrating clients and services with one or more infrastructures. The Proxy pattern is described in [Buschmann 96].
Applicability to Other Viewpoints and Scale
The impact of Pottersville on management is a loss of control of the technology, IT functionality, and their O&M budgets to the dictates of vendor product releases. There are also impacts related to risk management. Vendor lock-in is often accepted with promises for future features that arrive later than expected, if ever.
The impact of Pottersville on developers is a requirement for in-depth product knowledge. This knowledge is transient, in that, it will be obsolesced by the next product release. Developers are on a continuous learning-curve tread-mill, gathering rumors and information about product features, product bugs, and product futures.
© Copyright 1999 William Brown, Raphael Malveau, Hays McCormick, Thomas
Mowbray, and Scott W. Thomas. All rights reserved.