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

Anecdotal Evidence:

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.

Background

The name Pottersville comes from the popular film "It’s 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.

General Form

A software project adopts a product technology and becomes completely dependent upon the vendor’s 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

Typical Causes

Known Exceptions

The Vendor-Lock-In AntiPattern is acceptable when a single vendor's code makes up the majority of code needed in an application.

Refactored Solution

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:

Variations

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.

Example

The following examples are three known uses of the Isolation Layer solution.

1. The ORBlite framework provides isolation of application software from multiple language mappings and network protocols. [Moore 97] ORBlite is based upon HP ORBplus. ORBlite was able to support multiple language mappings for C++ given the evolution of the OMG mappings during the adoption and revision process. [Moore 97]
2. Even though OpenDoc is no longer in the product strategy of its creator, there were some interesting technical approaches used, including the Isolation Layer solution. The OpenDoc Parts Framework (OPF) provides a higher level C++ programming interface to the OpenDoc compound document interface, defined in ISO IDL. OPF includes interfaces to operating system functions (including display graphics) as well as OpenDoc functions. In doing so, OPF provides source code portability interfaces for middleware, windowing, and operating systems. Compound document parts written using OPF can be ported via recompilation and linking to OS/2, MacOS, and Windows95. A testing capability called LiveObjects was available from the Component Integration Labs , the consortium responsible for OpenDoc. The LiveObjects testing approach will assure component portability and interoperability.
3. EOSDIS (Earth Observation System) is a large-scale information retrieval project funded by NASA. The EOSDIS middleware abstraction layer was used to provide isolation between application software and evolving middleware. Initial prototypes used a beta-test CORBA product. These prototyping efforts proved unsuccessful; largely due to difficulties in using the beta test product. Although program management acknowledged the need for future CORBA support, a proprietary Object-Oriented DCE extension was chosen for short term implementations. Management also did not want to rely entirely on proprietary interfaces. The situation was resolved through the addition of a middleware abstraction layer that masked the choice of middleware from EOSDIS application software. The abstraction layer hid differences in object creation, object activation, and object invocation.

Related Solutions

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 2017 William Brown, Raphael Malveau, Hays McCormick, Thomas Mowbray, and Scott W. Thomas.  All rights reserved.
For problems or questions regarding this web contact [Web Master].
Last updated: April 2, 2017