Antifragility—an adaptive form of stability
Do enterprises seek too much stability? Psychologists have long established that introducing delays between actions and consequences has a negative effect on the ability of a subject to assert control over a process. And it seems obvious: imagine trying to direct the movements of an automobile when there is a 1- or 2-second delay between movements of the steering wheel and associated movements of the front wheels.
At the same time, we all observe and experience how our bodies adjust to hard exercise with soreness—physiotherapists call it “delayed onset muscle soreness,” which initially occurs after we push ourselves beyond our normal workout pattern. But after a second or third episode of similar workouts, we stop experiencing that same level of soreness. We adapt to the heavier workload. It’s where the phrase “no pain, no gain” comes from. Pain in this case is actually a signal that we have pushed ourselves enough to get stronger.
Now consider how companies normally approach the way they operate or, more specifically, adjust their operations in response to market challenges and opportunities. Generally, they establish standard ways of working, or operational stability, designed not to change at all. When change is thrust upon them, companies create long-running projects that bundle together a number of changes, introduce those changes without embedding real-time feedback loops to measure and respond to outcomes, and seek to establish a new stability in operations until a new bundle of changes is implemented at some future time.
The common mental model for the design and operation of the modern organization over time is defined by long periods of stable operations, then major, disruptive, managed-from-the-top changes to operations with insufficient synchrony between action and outcome to accommodate control, followed by another long period of stable operations.
This model permeates most everything organizations do for “change management.” Consider the best practices established by many IT organizations that follow the Information Technology Infrastructure Library (ITIL) bible:
“Goal: Ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of Change-related incidents upon service quality, and consequently to improve the the day-to-day operations of the organization.”1
So far, so good. Who could complain about “efficient and prompt” and “improve the day-to-day operations?” But most companies turn this positive vision into a slow-moving, nonresponsive situation where permission to change anything must be run past a Change Advisory Board. On the surface, the goal seems admirable: avoid pain from change that disrupts operations. And if change is deployed very sporadically in huge bundles with few opportunities to accurately assess—in real time—the impact of that bundle of change, then a bureaucratic, top-down process is probably appropriate.
This issue of the Technology Forecast asks the question: “Is there some other way?” Going in, PwC assumed the answer had to be “yes,” because web-scale companies are accelerating through disruptive periods of growth with some pain (that they anticipate, embrace, and learn from), and there are few examples of catastrophic failure. What enables such success with change management when change is a constant? What can other companies learn from their approaches?
Business processes must be adaptive enough to deliver solutions for today’s problems and opportunities, not yesterday’s. And large enterprises today are often full of good ideas that would result in better processes—but they confront legacy IT systems and project management procedures that take too long to deliver the infrastructure and application changes needed to support process changes. Major culprits include the way IT manages change and the risks that system changes create for stable operations. IT reaches for stable operations by minimizing the frequency of code changes.
Contrast that approach with how web-based companies operate, even very large ones such as Facebook, Google, and Netflix. These companies strive for continuity of operations by embracing change. Some introduce new code to their production systems many times a day. The counterintuitive outcomes for web-scale companies are systems that are much better aligned to what the business needs today and more responsive to what the business will need tomorrow.
Large enterprises are beginning to learn from what’s happening in these web-scale companies and are trying similar approaches internally. They’re discovering that an “antifragile” definition of stability is emerging that builds on existing agile development principles. The notion of highly adaptive “antifragility” applies not only to IT specifically, but the business as a whole.
The article, “The evolution from lean and agile to antifragile,” on page 06 considers the many industries experiencing an unprecedented amount of stress and disorder. How can enterprises turn stress and disorder into a positive? One answer may lie in how some web-scale companies make frequent daily changes a routine part of their cloud-based services. That pace of change becomes possible at a business design level using an advanced form of agile development, and that ability to quickly shift direction can move an agile company into a hypercompetitive, more antifragile state. These companies are in some ways antifragile because they invite and can immediately adapt to shocks.
“Making DevOps and continuous delivery a reality” on page 26 explores the practical application of continuous delivery. In continuous delivery, frequent—even daily or hourly—incremental code releases replace what previously transpired across weeks or months. Enterprises in established industries are now moving toward more frequent code releases with many of the same tools and techniques in use at web-scale companies. The fact is that startups and established organizations alike are using new tool chains to accelerate code delivery and deployment while paradoxically reducing the unintended introduction of bugs and the need for code fixes.
“A CIO’s DevOps approach to resolving the agility-stability paradox” on page 46 sheds new light on what stability is in the era of the cloud and how it is best approached. For decades, CIOs have applied methods and adopted tools that lead to at least some form of stability. But CIOs must change the IT mindset about how to achieve stability. The key is to adopt a DevOps philosophy that emphasizes speed and efficiency without sacrificing true stability.
This issue of the Technology Forecast also includes interviews with executives and subject matter experts who have been at the forefront of development in this area:
Please visit pwc.com/techforecast to find these articles and other issues of the Technology Forecast online. If you would like to receive future issues of this publication as a PDF attachment, you can sign up at pwc.com/techforecast/subscribe.
As always, we welcome your feedback and your ideas for future research and analysis topics to cover.
1 “ITIL Change Management,” http://www.itlibrary.org/?page=Change_Management, accessed June 14, 2013.