End Of Life Questions: Development and Support

By Michael Lynge On October 29, 2009
No tags assigned.

An end-of-life (EOL) announcement on a product that is an integral part of your test strategy is disruptive to schedules, and possibly revenue, as gap analysis is done and transition plans are formed. On the other hand, it forces you to evaluate your lab infrastructure against available solutions, an important exercise that is often pushed to the back burner in the urgency of day-to-day operations and task oversubscription.


The key issue in creating an EOL response strategy is support. It sets the ultimate deadline for the completion of your transition plan. However, in most cases the best strategy is to begin the transition sooner rather than later.

An EOL decision on the part of a vendor signals that the business case for the product is no longer viable. As such, diminishing resources will be devoted to support until it hits the EOL date, at which time support is no longer available. Issues that require bug fixes or development are likely to be a low priority, or even a no priority, for the vendor, leading to frustrating support calls with an unsatisfying resolution when problems arise during testing. The impact to development schedules and delivery/deployment dates can be significant.


The problem of diminishing support is exacerbated by diminishing, or non-existent, development for new technologies. A vendor is unlikely to add new protocol coverage, or even enhance coverage of an existing protocol, on a platform that has been officially identified as lacking a viable business case.

As we all know, the telecommunications industry is a fast-paced environment where working groups and committees constantly issue new drafts of recommendations and standards for cutting-edge technologies to address the challenges of delivering faster and more diverse content to consumers with endlessly expanding expectations. An EOL target of five years in the future isn’t the gating factor in your decision for when to start the transition. It’s the date when the schedule says you have to test a must-have feature that can only be delivered by supporting that new draft.

Going beyond protocol support, there are the issues of features and performance. A product under development introduces new features to enhance productivity and ease-of-use. A product in EOL leaves well enough alone, meaning you won’t be able to take advantage of productivity gains provided by a platform in active development.

In addition, new technologies place increasing demands on the solutions you develop, requiring greater power and performance from the device or network you deliver. This places greater demands on your test infrastructure to deliver corresponding performance increases. If the test platform can’t keep up, your budget or your schedule, or both, will suffer. A product in EOL will not have the benefit of on-going focus on the performance improvements your test lab requires. So, once again, the gating factor on your transition decision is not the EOL date, but your testing requirements.

An EOL announcement is usually unwelcome, but it can also be a wake-up call to find the best-of-breed solution on a platform with a clear future and a commitment to supporting technology at the bleeding edge. Not only will your productivity and reliability improve, you’ll avoid facing another EOL situation in the future.


comments powered by Disqus
× Spirent.com uses cookies to enhance and streamline your experience. By continuing to browse our site, you are agreeing to the use of cookies.