Cautious Buy Over Build

[ComponentDesignPatterns | CategoryPattern]

Context

You are determining the requirements for a solution that will contain both pre-built and custom-developed components and frameworks.

A pre-built component exists that might meet requirements.

Problem

How do you decide whether to acquire pre-built components or develop them yourself?

Forces

Developing software is expensive; we can save time and money by reusing it.
Too many pre-built components are difficult, complex, and frustrating to assemble.
Assembling pre-built components requires less expertise than developing them.
Assembling pre-built components requires understanding assumptions about underlying component implementations, and less skilled developers can get in trouble and not know how to get out..
Developing components gives the developer more control over implementation, coupling, and interactions with other components and frameworks.
Skilled developers are a scarce resource that are better used developing the solution than developing infrastructure components and frameworks that can be purchased elsewhere.
Pre-built components often have bugs, and always make assumptions. These assumptions are usually difficult to change, so you need to understand their implications on the rest of the system and whether the components will fit in.
Skilled developers can be motivated by NotInventedHere syndrome and may be inclined to blindly choose the build option over the buy option without a full assessment of the merits of each existing alternative.

Solution

Be cautious about acquiring pre-built components. If team-members already have experience with the caveats and problems surrounding a component and are confident that using the component will make their life better, go with it. If you don't have experience, get experience before you made a decision. A man-month or two spent experimenting can easily save man-years down the road. One quick way to get experience is to hire a new team member with it.

If you decide to use a component, decide early whether you couple yourself to it or explicitly decouple/protect yourself from depending on it.

Resulting Context

If you acquire an off-the-shelf container application that acts as a pre-built solution framework, your solution could likely benefit from ContainerIndependence.

Assess whether BypassingAbstractions is an alternative in the event that functionality you depend upon in an acquired component or framework doesn't meet requirements.

Known Uses

Global Investment Bank Project:

In a client contact management application this pattern was used in three major areas where components or frameworks were acquired as opposed to developed: for the purchase of a generic contact management framework, for a grid component, and for a CORBA-based middleware product.

The generic contact management framework, based on COM and ODBC, was acquired and acted as a container for components developed to provide contact-centric financial data and market feeds.

An infrastructure framework was built and layered on top of the contact management framework (in that all developed components extending contact management used this framework, which in turn was linked to the contact management framework) and facilitated ContainerIndependence. Components could be plugged into other frameworks if required (a simple and lightweight test framework was utilized for rapid development, design, and testing iterations).

Each component plugged into the container and was called in response to various state transitions in the container (e.g, resizing of the window, change of the currently selected contact, etc.). The component's infrastructure framework interacted with the contact manager through a singleton proxy as if it were another component when various state transitions occurred in components (e.g., the user clicks on a piece of data that results in a change in the currently selected contact in the container).

By being cautious about the decision for (instead of against) large-scale reuse of a generic contact management framework, our ability to rapidly test and fix bugs was increased dramatically, we were able to demonstrate their flexibility in demonstrations to users by showing the components plugged into a web browser, and we were protected in the event that the framework didn't meet requirements and other alternatives needed to be considered.

Most components used a grid component to display financial information to users in a tabular format that allowed them to sort and filter based on their preferences. Since grid components were inexpensive, and there were at least a dozen on the market, we sought to reduce the cost of switching to another grid because of bugs or lack of meeting requirements. We used the AdapterPattern to decouple each grid component from direct dependence on the proxy class that provided linkage to the grid's methods and properties.

Each of these components used middleware to request its data from an application server developed in C++ that existed on a different platform across the network. Early on, it was decided to couple the components to this middleware technology. But still -- in the event that for some crazy reason it couldn't be utilize it as the middleware solution -- a base class that hid most of the CORBA interaction from components was developed, a ConnectionSingleton was developed to manage the server connection, and subclasses from a base grid class were designed to move data from members in CORBA sequences to cells in the grid component.

Example

Related Patterns

One of the forces is that we've all been bitten by supposedly reusable components that are too inflexible, too resource hungry, or too buggy. This makes us skeptical of buying things. On the other hand, there are more and more good components, so more of us are having good experiences. If we are overly cautious then we need to be encouraged to buy. But how do we know if we are overly cautious, or just properly cautious?

Another force is that whether we should buy or build depends on the cost. As the speed of software development goes to infinity then the value of reuse goes to zero. (Neither is very close at the moment!) But it doesn't take very long to write something small, so it isn't worth much to reuse it. That is why companies like SAP are doing well; large scale reuse is worth more than small scale reuse.

-RalphJohnson

Ralph, thank you for making updates to the pattern -- they were subtle but made it a lot easier to read. I think this is an important pattern for projects. I hope we can not only capture how to help projects make more informed decisions, but also have a clear resulting context that helps them understand which subsequent patterns can help once they've arrived there.

PhilipEskelin

In joining a weekly patterns meeting at Micromodeling Associates in early December '98, we discussed CautiousBuyOverBuild. One person mentioned that we should reference ScottAmbler's work Process Patterns book(s) regarding buying over building. Another comment was that this wasn't a design pattern, but more of a "decision-oriented" pattern (would a good taxonomy be decision and design patterns?).

I agreed -- as I don't think any of us were ever under the impression that this was a design pattern -- but it made me think that the label for this entire language might be what caused confusion. It helped me realize that labels aren't everything, but they can help set a context and expectation for everything that follows.

Also, we briefly discussed the momentum behind Open Source Software (OSS) [1] and how it might affect buying over building. I don't think the focus was upon whether people would snatch code and tailor/control it under their own development environment; more that it might perhaps affect the quality and accessibility of software and components that would be freely modifiable by capable and interested folks.

One obvious suggestion that doesn't seem to be emphasized currently in the pattern is that investing time into researching existing components in the industry is important.

Finally, there was an assertion that acquired components always have bugs. This may seem pessimistic to marketing types or people who haven't tried to assemble third-party components into a solution, but it's always true. You only have an edge when you've had experience with the problems from components in the past.

Anyway, let's factor these comments into the pattern and see what comes from it . . . discussion/comments? --PhilipEskelin

What about making sure you have an exit strategy? Make sure that switching from the pre-existing component to something self-built or some other component, isn't too expensive. -- StephanHouben

JamesMcGovern

One of the things that complicates this decision is when corporations buy packages such as Siebel or Peoplesoft and customize the snout out of it. In this situation, maybe the best approach to customization is through the use of a ServiceOrientedArchitecture and Loosely Coupled customizations. The customizations should become a layer themselves.

CategoryStory