Category: Softwares

I feel there is a certain irony in trying to impart something about architectural ideals, when the very premise I wish to begin with is that effectively there are no ideals. If this is indeed the case, then surely there is nothing to write, I am a contradiction and by doing this I run the risk of the universe imploding or something like that.

But alas, ceci n’est pas une pipe.

One of the most valuable lessons that I have learned as a software architect is that context is king, and simplicity its humble servant. What this means in practical terms is that context is the only force that trumps simplicity when making architectural decisions.

When I say context, I refer not only to high-level, immediate forces such as key business drivers, but also to elements in the periphery, such as emerging technologies and thought leadership on diverse topics. Indeed, good architects keep track of several fast-moving targets.

What constitutes good architecture? It is the product of decisions made within a context usually tainted with multiple competing priorities. Those competing priorities mean that sometimes the most important decisions are not about what you put in, but rather what you omit. The currency of good architecture is simply astute decision-making (while the products are all only about communicating your intent).

Historically, there have been some fascinating examples of the influence that context can have on architecture. A favorite example involves the database selected to support an ambitious new software system for a modern battlefield tank [1]. (Deciding what database to use is not usually architecturally significant; this example merely serves to illustrate a point).

When it came time to choose the database, the team assessed many. They found that while the tank was moving quickly over undulating terrain while tracking a target, the majority of the databases were capable of supporting this maximal throughput required of the navigation and targeting systems. But they were taken by surprise when they discovered that firing the main gun on the tank caused such a strong electromagnetic pulse that it totally crashed the on-board systems and of course the database along with it! On a modern battlefield, a tank without its software running is quite literally in the dark. In this context, recovery time was the overwhelming factor in the choice of database, and no database did that better at the time than InterBase [2], and that is why it was chosen for the M1 Abrams tank.

So, while newsgroups rage with the flames of technology debates of X vs Y, it is idle amusement. The reason these debates rage is often not because of huge disparities in their technical merits, but rather because there are more subtle differences between them, and what features individuals value more than others when there is no guiding context to act as a trump card.

Your team should be free of ideals, reflect on context in the first instance, and reach for the simplest solutions from there.

Footnotes
[1] – A tank, despite its extremely dubious purpose, is still an engineering marvel.
[2] – Interestingly, InterBase had an architecture that caused disk-writes to leave the database in an always-consistent state. This is one reason that contributes to its ability to recover from hard failures so quickly.

Hardware is fallible, so we add redundancy. This allows us to survive individual hardware failures, but increases the likelihood of having at least one failure present at any given time.

Software is fallible. Our applications are made of software, so they’re vulnerable to failures. We add monitoring to tell us when the applications fail, but that monitoring is made of more software, so it too is fallible.

Humans make mistakes; we are fallible also. So, we automate actions, diagnostics, and processes. Automation removes the chance for an error of comission, but increases the chance of an error of omission. No automated system can respond to the same range of situations that a human can.

Therefore, we add monitoring to the automation. More software, more opportunities for failures.

Networks are built out of hardware, software, and very long wires. Therefore, networks are fallible. Even when they work, they are unpredictable because the state space of a large network is, for all practical purposes, infinite. Individual components may act deterministically, but still produce essentially chaotic behavior.

Every safety mechanism we employ to mitigate one kind of failure adds new failure modes. We add clustering software to move applications from a failed server to a healthy one, but now we risk “split-brain syndrome” if the cluster’s network acts up.

It’s worth remembering that the Three Mile Island accident was largely caused by a pressure relief value—a safety mechanism meant to prevent certain types of overpressure failures.

So, faced with the certainty of failure in our systems, what can we do about it?

Accept that, no matter what, your system will have a variety of failure modes. Deny that inevitability, and you lose your power to control and contain them. Once you accept that failures will happen, you have the ability to design your system’s reaction to specific failures. Just as auto engineers create crumple zones—areas designed to protect passengers by failing first—you can create safe failure modes that contain the damage and protect the rest of the system.

If you do not design your failure modes, then you will get whatever unpredictable—and usually dangerous—ones happen to emerge.