Trade-off intelligently is an art to sustainable innovations. In 1994, Imperial Japanese Navy(IJN) launched the 1st first Japanese-designed dreadnought battleship: Fusō. With 2 big renovations, Fusō has the most impressive pagoda mast of all time, aka a 40m-tall “Christmas tree” 🎄. Unfortunately, it’s not very practical. Not even as a lucky charm when Fusō was sunk by 1 torpedo at its 1st actual combat: Battle of Surigao Strait in 1944.
No doubt, there were many good reasons for IJN continuing to modernize Fusō, e.g. Washington Naval Treaty gave everyone “Battleships Holidays” from 1922. Arguably, even clavier designs packing so much new stuff into the superstructure: pagoda mast. However, they were also the steps leading Fusō to a tragically short endgame. A lesson learned: keep adding good stuff may make perfect sense at the time, but can also ruin a product eventually.
What can we learn from this story in a platform or product building? Let’s walk through an ongoing transition from 32-bit to 64-bit only in the consumer computing mass market. How a simple case takes 10 years. And why a few pushes are needed to turn a diverse ecosystem.
A simple case = 10 years
It takes Apple 10 years to move iPhone & its app ecosystem from 32-bit to 64-bit only. Which is not only the 1st but also the shortest in the mass-market computing history đź‘Ź.
- 6 years to adopt 64-bit: Apple introduced its 1st 64-bit device: iPhone 5S powered by Apple’s iOS 7 & A7 chip in 2013.
- Another 4 years to completely remove 32-bit legacy & apps out of the equation: Apple removed 32-bit app support for iOS 11 in 2017. So, the iPhone compute stack HW & SW won’t become a tall “Christmas tree 🎄”.
Between 2013 & 2017, the iOS app ecosystem was “fragmented” a bit. Because to reach all iOS users, an app had to be built & supported both 32-bit & 64-bit variants 🤹. Of cause the transition will never be perfect & even painful for many, Apple did a good job to manage planned obsolescence to move its ecosystem forward.
Note: even planned obsolescence can be used for good too. e.g. if one does so by offering to continue updates to the existing products with high user values without a high direct cost, everyone wins. Only, this strategy works better for SW over the HW because they have very different marginal costs. Psst! There are business models may work better for this too, try: Software as a Service(SaaS).
A complicated case
Today, it’s easy to see iPhone shifting to 64-bit is an obvious step forward because of many benefits: bigger/richer apps, better performance & security even. But at the time, there were doubts, such as QCom’s 64-bit was a “marketing gimmick” argument. To be fair, such a move was indeed too “visionary” back then. e.g. for QCom as a chip vendor, its customers are the device makers instead of end-users. It’s not easy for QCom to see why any device maker wants 64-bit, such as the memory space larger than 4GB. For example,HTC One only has 2GB RAM, which is a top premium phone in 2013.
Also, such change is complicated & will take a long time due to many external interdependencies in a diverse value network involving: semiconductor IPs, chips, OS, devices to apps. Lucky Apple, it can make such a bet & accelerate the transition all almost by itself & driving its app ecosystem forward. For Android with open HW & system ecosystems, such transition will take much longer & requires much more external forces.
First, the market competition pulls everyone going for 64-bit. In 2014, Android 5.0 introduced the platform support for 64-bit. Which is easy when someone, e.g. Apple has led the way.
Then, removing 32-bit fully from the value network is much more complicated. Not just there is little motivation & even resistance, but also difficult to align all parties for actions for the common good. A classical case of the tragedy of the commons. For example, who has the time to update existing 32-bit apps without a good reason.
Therefore, there has to be a force to push the ecosystem forward. In 2019, Google Play supports that by asking for 64-bit app support from the developers. Now, Arm introduces ARMv9 architecture, excusing new chips from 32-bit legacy. So, SoC vendors & device makers can ship 64-bit only devices in 2022, e.g. by Cortex-A75 + A55. Even the little cores still support 32-bit, it does not mean a system has to use it. By 2023, Cortex-A710 + A510, pure 64-bit big+little cores with 30+% performance & sustained efficiency pumped may power more premium mobiles then.
Stay lean & balance
They used to say “Nobody ever got fired for buying IBM”. Indeed for the short term, it’s so easy to let path dependency taking us to the same old spot. Whereas changing any course is risky. It’s even harder if to remove legacy “white elephants” in a product or platform. However, if no one is the force of lean, a team is likely building a huge “Christmas tree 🎄”. In the end, either someone to pay to clean that up or disruptive innovators will eventually.
One heuristic may be useful: whenever adding a thing, one can challenge to remove something as fit too. Stay lean & keep your balance.
Bonus: the proliferation of ARM core + GPU SoC is “eating Intel’s lunch” to be the next generation of “metal” for consumer computing. This is indeed a key step change for mobile. But why stop there, you will see such a change in notebooks, tablets, Smarter cars, desktops, Micro Data Centers, etc. sooner rather than later.
Full Disclosure
The opinions stated here are my own, not those of my company. They are mostly extrapolations from public information. I don’t have insider knowledge of those companies, nor a whatever expert.
