IT professionals know the phrase "future-proofing," whether from an infrastructure, network, storage, or application development perspective. The idea behind future proofing is that it “is the process of anticipating the future and developing methods of minimizing the effects of shocks and stresses of future events,” as defined by Wikipedia. Yet in this anticipation, technologists tend to create features and redundancy that may never be needed.
The software development life cycle is often referred to as building a house, having a sturdy foundation to build amazing applications: But the reality is that the software development life cycle is more akin to building a beautiful garden in harsh conditions. It is the idea of learning how to navigate landscaping challenges, whether by discovering innovative solutions, employing best practices, or discovering what can thrive in those conditions.
[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]
SLDC: Reality vs. myth
If you look at your software like a house, you will assume some pieces of your foundation never change – but working with that assumption is incorrect as we have seen the constant changes and technological improvements within computing over time. If this perspective of the software development process does not change, the fallacy of software foundations rarely changing will continue.This is dangerous because it can lead to excessive tech debt and legacy software, which is neglected behind the idea of “don’t fix it if it isn’t broken.” I have seen outages and large scale security breaches due to this mindset.
The reality is that IT landscapes often consist of massive properties with a series of houses, surrounded by outdoor gardens which are constantly tested by the elements, which leads to small destructions or large growth.
To this end, Claus Jensen, Chief Digital and Technology Officer of Memorial Sloan Kettering Cancer Center, says he has followed a stringent belief that a solution is only as strong as its weakest link. “You never know what that weakest link will be a couple of years from now,” Jensen says. “Not only do you need to build for technical change, you must take into account both talent change and business change as well. As an example of talent change, think about how difficult it is to find mainframe talent these days. On the business side, in healthcare, expectations and needs have changed rapidly the last 9 months, and what looked like robust clinical solutions back in 2019 are now inadequate to meet patient expectations and needs in a hybrid care model.”
Future-proofing ensures future neglect; antifragility ensures handled failure and change.
As Nassim Nicholas Taleb writes in "Antifragile: Things That Gain From Disorder," "Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better."
When you begin to look at your software landscape as a garden which needs to be regularly kept, groomed, modified and improved, your software development life cycle will naturally be modularized – with the idea of easily updating and replacing faulty and dying applications. This allows you and your organization to rely on software design principles such as do not repeat yourself (DRY), separation of concerns, code abstraction, and automation-first strategies.
When stressors happen within or outside of your IT landscape, does your system improve because of it, stay the same or break?
Every piece of your software, from the application down to the server or cloud provider tool, should be examined as a part of the landscape you are either creating or inheriting. Chaos Engineering, as coined by Netflix in 2011, has a similar mindset to antifragility and is a less complex way of looking at your software. Instead of constantly trying to predict the future of what your customers may need, your organization may need, or world events such as a pandemic or economic downturn, create a software landscape that can handle and grow with such change, instead of staying the course in spite of it.
4 pillars of an antifragility mindset
The pillars of antifragility in your IT landscape, if you’re moving from a future-proofing mindset, should include:
1. Redundancy:
Examine where redundancy can be improved in your systems for minimal cost and effort. Examine where might the largest cost occur if something goes down. How would the system respond if your cloud provider shuts down for 4 hours; what would the business impact be? Not all redundancy is bad, operating at the edge of efficiency makes you fragile – as we’ve seen with companies in this pandemic becoming winners and losers, and as we’ve seen with previous financial crashes and data breaches. Do not create redundancy for redundancy’s sake; understand the business, risk and cost impact of every decision and be intentional about those decisions.
2. Strength in stress:
Push your software to its limits by testing how you can increase the stress on your software to help build it stronger. Regularly run stress testing if you don’t already.
For example, Taft, Stettinius & Hollister LLP, CIO Andrea Markstrom says, “We always build in room to scale through threshold limits. We do not run at capacity, but we do run efficiently. We are always prepared to scale up if we need to quickly.”
This allows the organization to acquire and integrate new law firms at a moment’s notice. When the pandemic hit, their firm had zero downtime when moving their associates fully remote, due to the business continuity exercises which the firm regularly runs to push to the limits and learn from weaknesses to grow.
In your own life, when working out and lifting weights, your body hurts for a moment, but then it becomes stronger because of the stress you put on it. Your IT and your product and business should be no different.
3. Chaos engineering:
This has become standard at many organizations, but it can be deprioritized in times of immense growth and immense downturns. Focusing on engineering for faults and at the very least understanding where the issues may arise is insightful and necessary for an antifragility mindset.
When the pandemic hit, the airlines’ pricing engine did not account for the lack of travelers because the developers did not test for the “impossible” – so flights plummeted to record lows. Keeping the “impossible” in mind while building products is necessary for longevity and success.
4. Experimentation:
Creating new ways of working, new ways of thinking, and new ways of delivering customer value is where you can find new ways of gaining strength in times of greatness and in times of uncertainty.
Google became wildly successful because of its dedicated innovation and experimentation time. Other companies have established experimentation and innovation time within certain epics or even as small as sprints with their application teams to try something new or think of new ideas. In the well-known agile and DevOps books “The Phoenix Project” and "The Unicorn Project" by Gene Kim, the company creates new teams specifically designed for experimentation, a practice not very different from R & D teams at a pharmaceutical company or engineering groups.
Benefits for your organization
By primarily following an antifragile mindset, instead of the mindset of optimization and cost-efficiency only, an organization will improve the value delivered to colleagues and customers.
IT has invested too much time and money in an attempt to protect itself from an imaginary future that may never come to fruition. Great IT leaders focus instead on how to gain strength from adversity and achieve positive disruption through antifragility.
The real test for growth will happen when your IT landscape, your applications, and your business will not only handle the stresses that are thrown at it, but also grow and be better because of it. Redundancy is essential, strength is built through stress, chaos is assured, and experimentation and risks, big and small, are key to building something truly antifragile.
[ Get the free eBooks: Getting Started with Kubernetes and O'Reilly: Kubernetes Operators: Automating the Container Orchestration Platform. ]
