How fast is the world changing, and what can you do to thrive in it?
In this world of ever-increasing changes, how do we adapt to life? Also, is the rate of change going up? Also, if it is, then what can we do to thrive in these periods? Not just be shielded from the negative aspects of it.
The idea that change is accelerating is not novel. It’s Moore’s law from 1965. Back then, engineer Gordon Moore observed that the number of transistors in a dense integrated circuit doubles every two years. The Coronavirus also spreads exponentially, and the Omicron variant has a doubling time of two or three days. And we struggle to come to grips with understanding how fast that is. We struggle because we don’t have an intuition for things that grow exponentially. If you could fold a piece of paper 50 times, what do you imagine its thickness will be?
(Hint: Think moon shots! )
Today, the amount of data in the world is doubling every two years. Coupled with the climate crisis, the rise of artificial intelligence, and today’s extreme levels of connectivity — more than 4 billion people are now using the internet — we can understand why the term “disruption” has become a favorite among business thinkers and other commentators.
“They said that change was accelerating in 1900,“ Chris McKenna from Said business school in Oxford reminds us. “They said it in 1920. In 1940, in 1960, in 1980, and in 2000. So the presumption is that the people who said it before were wrong, but we’re right now.” Before the telegraph, information traveled at the speed of a horse. That’s the most significant transformation one could imagine in the world of information. And the web hasn’t done that. So, there is a point of diminishing returns that we have hit; we have far too much information to do anything meaningful with it unless you actively and intentionally pursue that path.
The First Industrial Revolution used water and steam power to mechanize production. The Second used electric power to create mass production. The Third used electronics and information technology to automate production. Now the Fourth Industrial Revolution is building on the Third, the digital revolution occurring since the middle of the last century. It is characterized by a fusion of technologies blurring the lines between the physical, digital, and biological spheres.
Quoting from the novel Children of Dune, “Everything remains mobile in the desert or perishes,” and quoting from Heraclitus, “you cannot step into the same river twice,” how do we design our lives for this constant change?
To phrase it technically, how do you architect your life for constant changes. One helpful analogy would be to think about Architects in IT environments. Architects typically live in the first derivative, and their job is to ensure that the company they work for or the building they are designing is architected for change. The architect needs to ensure that the tall building will withstand the stresses of an earthquake and high winds for a building. For a cloud architect, their job, among other things, is to ensure the availability of the software to their end-users regardless of scale, all the while ensuring the software can absorb changes when new features are added(and that is daily) without things breaking. Companies such as CapitalOne report deploying up to 50 times per day for a product, and Amazon, Google, and Netflix deploy thousands of times per day (aggregated over the hundreds of services that comprise their production environments).
Architectural decisions are fraught with tradeoffs. The cost is an obvious one. If you want reinforced steel, you pay a higher amount, but concrete structures are weak in tension, so steel reinforcements are provided to take the tensile force. So, that is an obvious trade-off to make if you have the budgets to allow for it, but in other aspects, some of the other examples are less obvious. What about availability in IT systems and software. 100% availability is to be aimed for; that’s obvious, right? But that could mean new features are not pushed to production, and we are not failing enough. To learn, one needs to experiment, fail and learn from failures. If an experiment’s success is pre-determined, then is it an experiment?
“I never once failed at making a light bulb. I just found out 99 ways not to make one.”
Thomas Edison
“Failure is an option here. If you are not failing, you are not innovating.”
Elon Musk
Andy Jassy used to say that there is no compression algorithm for experience. When you are at the forefront of building new technology or innovating with existing technology at an unprecedented scale, you will encounter challenges and successful failures. If you learn from those failures and put checks in place, your system will be anti-fragile to similar failures. Also, when setting OKRs in Google, if you hit 100% of the goal, that usually meant you were not aiming high enough. The sweet spot is hitting between 60–70% of the goal set.
When you are building systems, you want to ask which type of system are you building(be it at work or on the personal front)
Robust system- which can resist failure. e.g., hardened glass, IT systems with some redundancies at certain lower layers of abstractions but not multi-region redundancies
Resilient system — which can recover from failure. e.g., Sponge, Spring, IT systems with redundant architectures and a functional Disaster Recovery setup
Anti-fragile system- the ability to get better the more failures it encounters. e.g., Body’s immunity learns from pathogens and becomes more potent than before to ward off infections the next time it meets it, IT systems designed with Chaos engineering principles
Another tradeoff an architect needs to make is about ‘lock-in.’ We all value self-direction to some extent and will fight for it. We don’t want to be stuck with an internet service provider which is below industry averages, and we don’t have other options. Similarly, we don’t want to contract with enterprise vendors who are not very customer-obsessed. “It’s unhappy because those offerings are expensive, they’re proprietary, they have high amounts of lock-in, and those companies have punitive licensing terms, where they’re willing to audit you,” Andy Jassy said. “If they find any discrepancy, they extract more money out of you. And these companies also have no qualms about changing the licensing terms midstream on you.”
Below are excerpts from an excellent book by Gregor Hohpe called Cloud Strategy “one of the architect’s major objectives is to create options. Options allow you to postpone decisions into the future at known parameters. For example, the option to scale out an application allows you to add compute capacity at any time. Applications built without this option require hardware sizing upfront. Options are valuable because they allow you to defer a decision until more information (e.g., the application workload) is available as opposed to having to make the best guess at the very beginning.”
Another simpler example of an option would be to have two internet connections at home. If one fails, you switch over to another. But the downside of options is underutilization and complexity- I have to pay two bills. When my primary connection is working well, my secondary link is underutilized, so I end up paying more, but I get peace of mind while on work calls.
As Gregor Hohpe succinctly summarizes, “Avoiding lock-in is an abstract meta-goal, which, while architecturally desirable, needs to be translated into a tangible benefit. Don’t justify one buzzword with another one!”
But there is also a benefit from certain types of lock-in. One kind of relationship format that has been notably espoused ever since the agricultural revolution comes to mind(Hint:” Till Death do us apart.” A mutually beneficial lock-in can often be called a partnership. Back in corporate IT, some components might lock you into a specific product or vendor, but in return, give you a unique feature that provides a tangible benefit for your business. While we generally prefer less lock-in, this trade-off might well be acceptable. Gregor Hohpe offers a good example “not being able to take advantage of DynamoDB or Cloud Spanner because you want your solution to be portable across clouds bears a real, concrete cost of reduced features or value delivered. You’re paying with underutilization: a feature or product is available, but you’re not using it.
The cost of not using a feature is real and is incurred right now, whereas the potential return in reduced switching cost is deferred and hypothetical. It’s realized only when a complete migration is needed. Suppose your product fails in the market because avoiding a specific service led to poor performance or a delayed launch. In that case, the option of a later migration will be worthless because your product won’t be around.”
On the personal front, I am happily locked into an Apple iOS ecosystem because I appreciate the design of apple devices and seamless integration across services & devices.
While architecting aspects of your life, you will need to make these trade-off decisions. Be it in the realm of work(software architect or building architect), finances(investment portfolios with diversification), or relationships- when you are architecting aspects of your life, ask whether you are designing a fragile, robust, resilient, or antifragile system for yourselves and those around you. I will be that you(and your family) don’t want to be living in a building that is not designed to withstand earthquakes or heavy winds, regardless of how rare an occurrence it was in the past. With climate change, even more so.
Opinions expressed are solely my own and do not express the views or opinions of my employer.
