BASCRI

The Force Behind All Those Upgrades

by W. Bradley Holtz

Why do we always have to upgrade our hardware and software? Is there some driving force, like entropy, that makes it impossible for anyone to just hold fast with the status quo?

I believe that there is such a "force" and I have named it the BASCRI (bass-kree) cycle. It is because all software and most hardware follow this cycle that we are doomed to a continuous roundabout of upgrades.

The quality, robustness, and compatibility of software and hardware changes during a product’s lifecycle. At the beginning of a product’s lifecycle it may be relatively…

Buggy. New software in particular generally requires a great deal of non-productive time from users. This non-productive time is required to determine and fix any associated problems, document bugs, and discover incompatibilities with existing hardware and other software.

Most hardware drivers have not been released yet.

At this early stage, only the lead technology investigators within a firm would typically have access to the product, as it is generally too soon to deploy it throughout the firm. (AutoCAD release 13c1 was a good example of a product at this point in the lifecycle.)

As development continues, bug patches or fixes eventually become available and the systems start becoming…

Acceptable, for most purposes. While not completely bug-free, at this stage most problems are not disastrous, and some third-party products may have been upgraded to work with the product.

Drivers for many hardware and software applications are beginning to show up.

Firms with a strategy of using technology as a competitive edge generally choose to deploy software and hardware throughout their firms at this stage. These firms have determined that they can put up with the inconveniences of the product in exchange for the early technology lead over their competition. (AutoCAD release 13c3b was a good example of an acceptable version.)

After many bug fixes and patches, and in some cases new releases, products become…

Stable. Basically bug free, stable products can have long productive lives. At this stage many third-party products have been upgraded to work with the system and most drivers are readily available.

In general, most firms wait until products are at this stage before allowing them to be deployed to users throughout the firm.

When, after a significant period of time at this stage, products have been stable long enough that all third-party products work with the system that ever will, the product has matured to the…

Compatible stage. Essentially all the bugs are worked out.

Finding drivers to work with the system is now easy and the product is compatible with most (if not all) other hardware and software on the market. Firms have no reason not to deploy the product. The system is in its main useful life.

Eventually, the product matures to the…

Robust stage. It doesn’t break when new things are added to it; it works without problems. All drivers that ever will be written have been written. Life is good.

Unfortunately, about 5 minutes after products reach the Robust stage, all hell breaks loose and the product moves immediately towards being…

Incompatible. This is the end of the line for systems.

Somewhere along the way something new was added to the system. Whether a new component or product was added to the system or an old component was replaced, it is this item that drives the BASCRI cycle. This new or replacement component will have different requirements that the current system and these new requirements necessitate upgrading or replacing other components of the system. Drivers may be unavailable for use with newer system components. Requirements of new components may require more up-to-date systems to work with. The operating system may no longer support features that the system requires, and other problems will contribute to the demise of the system. There is no getting around it.

Suppose you have a system that does exactly what you want it to and you have absolutely no reason to want to improve it or change it. You can isolate that system from all others and it will still be subject to the BASCRI cycle for two key reasons.

First, hardware components do not last forever. Even the best hard disc will eventually fail, and other components have limited life-spans as well. Therefore, at some point, a component will need to be replaced.

Second, in order to remain competitive, hardware vendors continue to improve their products, but in general they do NOT continue to manufacture and stock older versions of their products. You can go out today and order a part from a 30-year-old car from many sources with relative ease. In the computer industry, the constant price/performance gains of the industry provide a strong counter incentive for providing exact replacements. There is a very small likelihood that any stocked historical part would ever be sold, making it cost prohibitive to provide comprehensive exact replacements. (Why would anyone in his or her right minds want to buy an older, slower, less reliable, more expensive item.) So when you go to replace that failed component, you will have to replace it with a more recent design. Replacing a single component initiates a cascade of upgrades of other components, hardware and software for the system, all subject to their own BASCRI cycle.

Many software systems never even get beyond the acceptable stage of BASCRI. The vendors of these systems are continually coming out with new versions, never stopping long enough to fix the problems with the existing systems. Hardware systems may be robust for some time after reaching the incompatible stage for use with CAD systems. When evaluating vendors, look at their product history with the BASCRI lifecycle in mind to get an idea of what you can expect from those vendors in the future.

Some might even go so far as to say that BASCRI is the upgrade "entropy" that drives our industry to drive the world economy!

Originally published by Start Magazine, 12/28/99, copyright 1999-2009 Cyon Research

Site Credits