Producers and users are both involved when a product, component, or technology is slated for obsolescence, but both parties do not always agree that the obsolescence is appropriate. Take for example Microsoft’s efforts to kill Internet Explorer 6 (IE6). The company recently launched a website called ie6countdown.com with the intent to track and encourage people to migrate away from the ten year old web browser. As of February 2011, 12% of worldwide users are still using IE6 as their browser – this represents a sizable group of people that present a support challenge for Microsoft and web content developers. According to Roger Capriotti at Microsoft, their goal is to get the worldwide share down to below 1% because they believe that 1% will allow more sites and IT pros worldwide to make IE6 a low-priority browser.

One thing I was not able to discover on the tracking website is the type of machine these IE6 users are running the browser on. I suspect that the underlying hardware may play a larger role in the continued use of the browser that will be three generations behind the latest browser (IE9) as of March 14^th.

For embedded developers, the obsolescence of components can wreak havoc. While the end user may not even be aware of the embedded systems in their end devices, changing the implementation of an embedded system is no trivial task. That is why on many aerospace programs I worked on we specified that the microprocessor that we selected must be available to support a twenty or thirty year support window. Now that did not mean the processor supplier had to keep manufacturing those processors for all of those years, but it did mean that there was a plan to pre-produce and store those processors against some usage plan for that period of time.

Part of the reason for continuing to use the older processors was that it was too risky and expensive to upgrade the system to the latest generation processors. Even though a processor may be fully backwards compatible, the interfaces and timing differences of system events could shift just enough to cause intermittent failures in the end system. To upgrade a processor would entail a complete recertification, and for some systems, that is an unjustifiable expense to only maintain the functionality of a system.

Maintaining older generations of components beyond their production life cycle can also apply to software modules. Changing the operating system in an embedded system may also require a recertification, so it is safer and more cost effective to freeze the operating system at a specific configuration and version.

How do you handle obsolescence – both as a producer and as a user? As a producer, this question is most interesting when your user base wishes to continue using your product beyond your planned production cycle. As a user, this question is interesting as a way to explore different strategies to maintain a frozen design or migrate the design without incurring product killing costs.

Tags: Obsolescence

This entry was posted on Wednesday, March 9th, 2011 at 3:13 pm and is filed under Certification, Question of the Week. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.