A few years back, a senior leader at a previous company decided that being “cutting edge” was a core value we should espouse and so we quickly became the Guinea Pigs of our vendors. I don’t recall them offering much, if any, of a discount, but they gladly pushed their V1 software to us and we were given a fast track feedback channel to the developers.
When employees weren’t able to get the needed access to our facilities and several service interruptions occurred, thankfully uptime became our top priority and we settled into V2 of stable release software instead.
Using proven mature technology means finding that sweet spot after the beta testers and before the end of a product development lifecycle (PDLC).
“How can we leverage the experiences of others and existing solutions to simplify our implementation? ... The simplest implementation is almost always one that has already been implemented and proven scalable.”Abbott, Martin L.. Scalability Rules. Pearson Education.
At the release of the first and second generation of the Apple iPad, I was one of the crazy fanboys who woke up in the middle of the night to camp out in front of the Apple Store to be one of the first in line. Because the incremental improvements in speed and features were substantial, I would quickly want to upgrade to the next version.
In contrast, my kids still use Generation 3 and 4 iPads bought used on Craigslist and eBay, and the devices work great for basic web surfing and streaming videos. I waited until V2 of the iPad Pro for my own tablet which I also bought used and at a substantial discount. The incremental improvements of each new generation have become more and more arbitrary for how I use the devices, and the ROI for these latter devices is at least 2-3 fold greater.
In the world of Microsoft software, SP2 is usually that Goldilocks time period where there is enough benefit to upgrade without taking on too much risk for larger organizations. As of this writing, NetMarketShare.com reports that Windows 7 is still being used by 38% of polled users and Windows XP is not too far behind Windows 8 for a combined total of just under 8%. Clearly, many – including non-profit and third-world countries – want the stability of a proven OS without the hassle and cost to upgrade.
The Sharpness of Cutting Edge
It is helpful to consider the following when making a decision about just how close to the “cutting edge” technology utilized should be:
- Scalability: Will the technology support growth spurts without worry of capacity?
- Availability: Reliable in the 99.9s with a large enough customer base that if you are experiencing issues, so is a much larger segment of the market and the vendor is incentivized to quickly patch and resolve
- Competitive Advantage: Your company is propelled to success, not hindered by the technology
If your decision to be cutting edge is not providing an easily-observable competitive advantage, then the risks are not bringing the needed rewards.
As in all decisions, we need to constantly be asking what is our desired outcome? And then regularly review if our priorities match our purchase and implementation of technology decisions. Bells and whistles are often underutilized and provide very little competitive or strategic advantage while increasing costs and providing distractions.
TECHNOLOGY ADOPTION LIFECYCLE
Use Mature Technology – not retired or dying technology
The corollary, of course, is not to get too comfortable that your technology becomes antiquated.
As technology ages, vendors increase the cost of support in hopes of incentivizing us to upgrade to the latest and greatest or move to a subscription-based model. Perhaps the largest cost to our business, however, is the loss of competitive advantage when precious resources are used to nurse aged systems, attend P1/Sev 1 escalation calls, post mortems, and quality of service meetings instead of developing the next-gen platform that will maintain or beat the competition for market share.
The largest cost to our business is the loss of competitive advantage when precious resources are used to nurse aged systems instead of developing the next-gen platform to increase and maintain market share.
Don't Hitch Your Wagon to a Dying or Dead Horse
As an extreme example of holding on to dying technology – many traditional banks, insurance companies, airlines, and others still use massive, monolithic applications written in COBOL. Outside of cost to change to a new platform, a justification we have heard from our clients to keep it alive is that COBOL programmers can make more because there are so few of them.
The higher pay, however, does not seem to drive new University interns and graduates who want to be part of the next Facebook, Google, or Apple to tie their future career to a dying language. The majority of COBOL programmers are currently retiring and will likely be out of the workforce within a decade which means the costs will continually increase until the supply is depleted. While it is not an immediately dire need to move out of COBOL, it definitely needs to be on the 3-5 year roadmap of how to transition to a more scalable, efficient, and easier to support language. For many organizations, it is like the ugly couch in a college apartment, no one really notices it is more than just an eyesore until a family of rats and lice are found to be living in it.
Unfortunately, with quarterly financial cycles, often the cost to move away from servers and software that have performed reliably for decades is a difficult cost proposition for operations teams. FAs – who's bonus and annual increase are reliant upon keeping budgets flat – aren't going to see the advantages. CTOs must take a longer term view of the cost to transition now verses down the road - and give a very heavy weighting to lost opportunity cost for not making the move sooner rather than later.
Conclusions
- Our technology solutions should always focus on what will lead to the most competitive take of market share
- Our technology must be both scalable and highly available
- There is a sweet spot to technology adoption that lies between early release and end of life that should be evaluated annually and the true cost of supporting beta and aged systems should be measured in both man hours for upkeep – but most importantly in how much it distracts our key talent from innovating the next BIG THING