Vendor Lock-in
                             Vendor Lock-in [1]Wolf Ticket


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:

                               lock-in.gif (63938 bytes)

                   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

   [rombul1a.gif] Commercial product upgrades drive the application software
   maintenance cycle.
   [rombul1a.gif] Promised product features are delayed or never delivered, causing
   missed application feature deliveries.
   [rombul1a.gif] The product varies significantly from the advertised open systems
   standard.
   [rombul1a.gif] If a product upgrade is missed entirely, then a product repurchase
   and re-integration is often necessary.

Typical Causes

   [rombul1a.gif] The product varies from published open system standards because
   there is no effective conformance process for the standard.
   [rombul1a.gif] The product is selected based entirely upon marketing and sales
   information, and not upon more detailed technical inspection.
   [rombul1a.gif] There is no technical approach for isolating application software
   from direct dependency upon the product.
   [rombul1a.gif] Application programming requires in-depth product knowledge.
   [rombul1a.gif] The complexity and generality of the product technology greatly
   exceeds that of the application needs; direct dependence upon the product
   involves lost management of complexity of the application system architecture.

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:

   [rombul1a.gif] Isolation of application software from lower-level infrastructure
   is needed. This infrastructure may include middleware, operating systems,
   security mechanisms, or other low-level mechanisms.
   [rombul1a.gif] Changes to the underlying infrastructure are anticipated within
   the life cycle of the affected software. For example , new product releases or
   planned migration to new infrastructure.
   [rombul1a.gif] A more convenient programming interface is useful or necessary.
   The level of abstraction provided by the infrastructure is too primitive or
   flexible for the intended applications and systems.
   [rombul1a.gif] It is desired to provide consistent handling of the infrastructure
   across many systems. Some heavyweight conventions for default handling of
   infrastructure interfaces must be provided.
   [rombul1a.gif] Multiple infrastructures must be supported, either during the life
   cycle or concurrently.

                               5fig5_12.gif (4157 bytes)

       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:

   [rombul1a.gif] Mitigates the risks and costs of infrastructure migration.
   [rombul1a.gif] Avoids obsolescence due to infrastructure changes.
   [rombul1a.gif] Reduces the risk and cost of software upgrades due to
   infrastructure changes.
   [rombul1a.gif] Provides a less labor intensive and inexpensive programming
   interface to most application programmers.
   [rombul1a.gif] Supports the concurrent use of multiple infrastructures. Does so
   transparently.
   [rombul1a.gif] Enforces coordinated default handling of flexible interfaces and
   parameters.
   [rombul1a.gif] Separates knowledge of infrastructure from application knowledge.
   Allows a small team of infrastructure developers to maintain the isolation layer,
   while the majority of programmers have a customized interface to the layering
   software.

   The other consequences of this solution include:

   [rombul1a.gif] Isolation layer must be migrated and maintained , potentially on
   multiple platforms and infrastructures.
   [rombul1a.gif] Coordination of developers required to define initial isolation
   layer interfaces.
   [rombul1a.gif] Coordination required to make changes to the application
   interfaces.

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.


                                    [romhorsa.gif]

                                 [2]Home [3]Up [4]Next

       � 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 [5][Web Master].
                              Last updated: April 2, 2017

References

   1. http://antipatterns.com/wolfticket.htm
   2. http://antipatterns.com/./
   3. http://antipatterns.com/arch_cat.htm
   4. http://antipatterns.com/wolfticket.htm
   5. mailto:skip@antipatterns.com