Is the newest model the best choice? The answer would be yes, right? Unfortunately, the answer is not that simple. There are many factors that influence the answer.
OEMs are constantly releasing new models. With each new model, the OEM proclaims it as an upgrade that it solves many IT problems. Not only are IT managers flooded with this information in OEM ads, they experience additional pressure while attending IT conferences and shows from both the OEM and other attendees. All this pressure pushes for a spontaneous purchasing decision versus a planned transition. When an impromptu purchasing decision is made, many IT managers overlook their multi-year plans and stabilization exercises. Is the offer provided by the OEM along with the outside pressure to buy worth discarding all the careful planning that has been put into place?
With every new piece of equipment released, OEMs advertise upgrades made over the previous model. Yet these changes between models are often minor and have little real-world impact. Most of us have had a similar experience even when purchasing consumer IT products. A feature is promoted as an upgrade, but later it is discovered the change/upgrade did not help in the way expected. In some instances, the changes made between models actually decrease the usability of the product thus increasing user frustration. In order for a model change to be accurately called an upgrade, its features must have a measurable benefit to the organization and IT department rather than some extra “chrome”. They should make a noticeable and valuable contribution to mission critical operations within the system’s environment. If the benefit is not significant enough, the older model currently in use may be the better option.
A general consideration for IT departments is if the inter-model feature change is significant enough to merit the additional work and increased capital expenditures. On release, often a new model has undergone only a few slight alterations since the previous model, sometimes just two or three. If these changed features are not vital for mission-critical operations, it may be wise to wait for one or two models to be released before upgrading. This waiting allows departments to jump over intermediate models and pay the price for one system replacement while accumulating multiple features instead of just two or three. This waiting allows for budget maximization while reducing downtime associated with system migration.
As with many other forms of tech, enterprise system models are not without their defects when first released. Often IT products display a bathtub shaped curve demonstrating the failure rates of systems and hardware. When a model is first launched it experiences soaring failure rates. After a while, the failure rate drops and the issues and bugs are worked out as the innovators and early adopters experience the problems. Often it is better to be a member of the early majority, or even in the late majority, on the product adoption bell curve as many of the problems will be fixed and the systems will be more reliable. Waiting too long, on the other hand, places users in the last 16% along with significant chances of system failure rates spiking due to the age of the systems.
Some IT products do not demonstrate the traditional failure rate curve; instead they demonstrate more of a flat or a steady increase in the failure rate. This unusual behaviour results from the root cause being impractical for the OEM to resolve or additional problems becoming apparent over time. For IT departments without unlimited funding, it is safer to remain in the early or late majority when purchasing and adopting the new model of enterprise hardware. New models are especially risky to innovators and early adopters as they have no previous history to determine whether the systems have a high failure rate and are thus unreliable. On the other hand, those following early adopters will know from their experience whether the model is a wise and safe investment.
When implementing a system swaps for new models, IT departments must determine their system swap procedure to avoid additional costs. There are usually two options when swapping a drive. The first is to maintain a redundant system for transitioning data and users to during the swap, while the second is to shut down the system and cut access to the data. Both methods for swapping systems generate additional costs either from purchasing and managing another system or costs resulting from downtime.
Choosing option two and shutting the system down results in down time. As many know within the IT field, downtime is costly. Probably the highest cost from downtime associated with a system swap is lost revenue. Following lost revenue, other costs are incurred, including those resulting from reduced productivity, lost opportunities, and decreased customer confidence. To avoid or reduce these costs, a solution must be designed around compatibility with existing infrastructure and employees’ usability to allow for a seamless transition. The lower the frequency of system swaps in an IT infrastructure the lower overall associated costs and downtime.
When considering upgrading to a new system, IT managers should consider the additional man-hours incurred as a result of the transition. Not only is work required to move the entire system that is being swapped, but work is also required to reconnect and troubleshoot potential compatibility issues. Once the system is in place, IT staff and company personnel must be retrained. Not only is this time-intensive for production and office staff, but it also requires a significant time investment from those providing the training. A major cost to organizations and their related IT departments is man-hours. As a result, efficient man-hour use is a major consideration for many IT managers so they can maintain their given IT budgets. Increasing the intervals between system swaps decreases the overall man-hour costs.
Many managers at this point are thinking about their legacy hardware and their related support and maintenance needs. The OEM places additional pressure to upgrade systems so they can sell more and increase their profit margins. They do not consider what is best for IT managers and their budgets as their goal is to increase sales. As a result, support costs skyrocket when it is time to renegotiate the SLAs. Once a system is sunsetted by the OEM, no support is provided by the OEM regardless of the price, leaving departments without support for functioning systems. Thomastech provides a solution.
With Thomastech’s support, many managers receive up to a 70% savings compared to the OEM’s SLAs. Thomastech focuses on streamlining and simplifying the support and maintenance process. Thomastech accomplishes this by providing direct access to level three engineers, extensive internal hardware inventory, support for all your OEMs in one place and a streamlined ticketing and triage process. All of these features ensure a faster resolution, lower costs, and reduced downtime.
What is SAN and How can it Benefit Your Company
Part 3 – Applying Third-Party Oracle and SAP Support to Reduce Costs in Unprecedented Times: Engage Your Stakeholders
Back to Basics: Cloud Storage
Types of TPMs
Saturday Spotlight: Mason Woodrum
What are Your Data Storage Needs?
Third Party Support