The dangers of life are infinite, and among them is safety.
Enterprises always assess value for serious undertakings and operations. The value coin has two sides to it — cost and benefit — that together determine whether to move forward with something. Or not. But the coin has an edge to it, too: risk. Nothing is guaranteed. Desires, intents, and the best-laid plans may face obstacles and challenges that can make the difference between success and catastrophe. Also, risk is not just about what we do; it is also inherent in what we don’t do. Standing still while the world moves can be as dangerous as moving out of step with real events. Architecture, too, like everything else, has risk, and it is probabilistic in nature.1
Is Architecture Normal?
The normal curve is a staple of statistical thinking. Many models assume normality, including financial models such as Modern Portfolio Theory, Efficient Markets, and Black-Scholes option pricing. But when human behavior is involved, normal can become abnormal in a heartbeat; models disintegrate, taking the reality that they model down with them. The financial industry has experienced this phenomenon and has done a fair amount of introspection about fat tail risk and the need to hedge against these kinds of risks that were realized to be less improbable than they were thought to be, prior to the 2008 financial crisis.
Architecture is often implicitly assumed to be deterministic, which is to say that it is beyond normal. We say we will do X and that doing that will result in Y. We project that there will be a certain number in dollar savings, a certain amount of revenue gains, effort required, time spent, and so on. The reality is that the mileage will vary, sometimes quite a bit, from projections. There are many variables that influence what happens in the real world when human beings enter and swirl in the mix of infrastructure, software, and services. Also, human behavior comes from different angles and spheres of life: from the people inside the enterprise, from external players who are served by the enterprise, from entities that govern, and even from people at large who have little to do directly with the enterprise.
In effect, the architect proposes and the rest of the world disposes. And if we were to plot out the various outcomes that actually result across a variety of architecture efforts, we are likely to find less deterministic patterns and more probabilistic ranges in which these results sit. We may want to believe that it would at least be something along the lines of a normal distribution that has less likelihood of straying too far from what we desired to accomplish. However, the reality may be more complex. The crocodile that architects tackle may have a tail much as the 2008 financial crisis did. And it may pack a powerful punch.
A Tale of Architecture Tail Risk
One very current example of architecture tail risk is the unforeseen events in Parler’s journey, as Amazon suspends the company from its Web hosting platform (within hours of this writing). The CEO says that the company had prepared for such an event “by never relying on Amazon’s proprietary infrastructure and building bare metal products.” It would seem to require the predictive powers of a Nostradamus to be able to foresee the sequence of events that led to the specific situation that Parler finds itself in, but it sounds like some architects made good directional thrusts that will enable this company to lift and shift its digital underpinnings to a more stable place.
There is more. Google and Apple have also removed Parler from their Play Store and App Store, respectively. It will be worth following this architecture tale as it unfolds over the next few weeks to see whether the architects did in fact outwit the crocodile’s tail that was hidden out of sight.
In the Parler example, the risk lay in human behavior from entities that lay well beyond what the company may have thought of as key decision makers in their fate. There are also many other tales that can be told that would point out other kinds of entities whose behavior and decisions might impact what an enterprise would do. There are people from the architectural trenches who can relate stories in which the “architecture as intended” did not quite pan out to be the “architecture as implemented” because there were people involved between intent and implementation who behaved in ways that were not foreseen. There are also tales in which the intent of architecture itself may have been out of alignment with the intent of the people who would actually use the results of the architecture, causing an unhappy state of forced coexistence between the two. And then, of course, there is nature itself — its crocodile tail can come in the form of a raging hurricane or a virulent virus that whips up human emotion along with its own biological rampage.
Parler, on the face of it, has hedged its architectural bets, if its CEO’s statement is correct. Architects in any enterprise would be wise to understand what kinds of tail risks exist, what kinds of hedging may be required, and how to go about building those hedges into the architecture so that their enterprise is prepared when the storm clouds do arrive.
Perhaps architects should consider adding the subdiscipline of “storm-cloud computing” to their skill base? Maybe we need to tell more tales of architecture tails, so that we are more aware of the existence of these and about the probabilistic nature of architecture? Tell me what you think. Send your comments to me at firstname.lastname@example.org.
1Cutter Senior Consultant Barry M. O’Reilly has written extensively on this concept, which he calls “stressor analysis.” For more on the topic, see “ ‘There Is No Spoon’: Residuality Theory & Rethinking Software Engineering.”