Architecture Decisions

This post is a preview or "trailer," of the slides and notes for my Visual Design and Architecture talk.

Architecture as Decisions

Many of us use Grady Booch's characterization of software architecture, because it captures so much in just a sentence:

"Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." -- Grady Booch

I've covered some of the implications of "cost of change" in earlier posts: Modularity Matters and Heuristics part ii: Decisions and Change.

Another Grady Booch insight strikes high resonance in our field:

"Every software-intensive system has an architecture. In some cases that architecture is intentional, while in others it is accidental. Most of the time it is both, born of the consequences of a myriad of design decisions made by its architects and its developers over the lifetime of a system" -- Grady Booch

For architecturally significant decisions, the accidental decision, or decisions that are made by virtue of not making an intentional decision, is a bad decision. Or, as Douglas Martin put it: "The alternative to good design is bad design, not no design at all." The question is not "does the system have an architecture?" but rather "how good is it?"

Decisions Constrain and Enable

To be sure, decisions constrain—they eliminate options. Alicia Juarrero observes that this is what we commonly mean by constraint—this limiting or closing off of alternatives; this altering of the probability distribution of available alternatives. But! In so doing, Alicia notes, they make the system "diverge from chance, from randomness."

Constraints close off avenues, restrict the degrees of freedom, but if this was all they did, systems, including organisms, would just do less and less, as they became more constrained (Alicia Juarrero*).

Instead, "constraints not only reduce alternatives—they also create alternatives." If we take (Alicia's example of) language, the constraints of syntax allow meaning to emerge.

Architecture decisions, at any point along our system's development path but especially early, "put ground under the feet" (Dana Bredemeyer) and enable us to "gain traction." They move us from potentiality to actuality—closing off options but enabling value to be created; to be able to move forward, we have to start to shape the space. To create a bit of clearing in the "great blooming, buzzing confusion" (James) or fog of uncertainty; to start to do something, and see how we're doing.

We build on these decisions, and they tend to become embedded within assumptions about what the system is, and does, as well as how it is built. Hence, we need to probe and test and improve these design ideas as quickly and cheaply as we can, while they are still reversible.

So architecture decisions are significant, because they enable the creation of value for users and (extraction of value for) the business. And need to be made intentionally.

The Architecture of Architecture Decisions

Various architecture decision templates have been published, including by Jeff Tyree and Art Akerman then at Capital One (in IEEE Software, so this template and discussion gained exposure and influence), and Olaf Zimmerman at IBM. But Michael Nygard's simplified (yet well-described) template caught on as a just enough version for documenting architecture decisions in an Agile context. The Architecture Decision Record, then, documents decisions in terms of the statement of the decision, the outcome sought and the forces weighed in the making of the decision, along with consequences or implications of the decision. (The Tyree/Akerman and Zimmerman versions also keep track of alternatives considered but ruled out, and this is valuable too.)

Now, it is tempting to think, given that it requires our expertise, that the decision is where our focal contribution lies.

Decisions are about Tradeoffs

But as architects (system designers with experience and senses alert to what has defining, success-shaping, consequences), we're seeking to surface what trade-offs we're making. In order to achieve the outcome we're targeting with the approach we're considering, what forces come into play, what are the downsides, what negative consequences do we need to seek to mitigate?

In this example, it is being pointed out that microservices help us achieve scalability and fault tolerance, but come at the cost of additional complexity in designing and managing distributed systems. Other gains include greater development team independence, which we see again in the next example.

Let's spend a moment and read this (below) from Mattias Peter Johansson on Quora, about Spotify.

We see that allowing duplicate instances of different versions of various libraries (reportedly) enables Spotify squads (teams) considerable independence, removing the need to coordinate with other squads on libraries and versions. Because song size so dominates considerations that it generally falls beneath the threshold of sensitivity for the user, the trade-off of team freedom for app size is easily (in their view) within the design acceptance envelope.

So in this case, a technical decision is being made for organizational gain (lowering team coordination costs and increasing team's degrees of freedom) at the expense of app size, which works as long as it's below the app user's tolerance threshold for resource consumption.

Tradeoffs Depend on Context

That Spotify example illustrates this point that Diana Montalion makes: "the value of every decision depends on the context in which we make it." Diana illustrates with The Lord of the Rings and Frodo's journey to destroy the ring: his quest is meaningful within that context.

Sarah Mei makes a related, important point: system quality is a joint property of the system and the context. Emergent properties, or quality attributes of the system, aren't in this or that line, or lines, of code—we don't see them, when we look at lines of code. They emerge from interrelationships within the system, and with the environment or context of use, for various contexts of use, as well as context of operation, and/or development context(s).

Multiple Contexts and Multidimensional Trade-off Spaces

The choices we're making are technical, but the impacts don't remain neatly in the technical space. The trade-off space isn't just about qualities that impact developer experience, or security properties or operational complexity, but user experience and partner experience through properties of the system in use. They might impact costs to the business or to users. And more. So we investigate the upsides and downsides of our technical decisions, in these various contexts.

[Aside: I had a version of Cook and Rasmussen's Dynamic Safety Model at this point, but it was one of the things I eliminated during practice runs of the talk, to bring it within 90 minutes. It can be used to inform how we think about technical debt, for example—in that case, we're dealing (in this view or modeling frame) with developer workload boundary and we can think of the "performance boundary" as the changeability or adaptability boundary (the failure threshold has to do with coupling and other forms of debt, that thwart adding features and raise cost of change). In the operations case, the performance boundary has to do with scalability and resilience—failures that cause loss and/or distress for customers and news vans to line up outside headquarters.... Etc. ]

"We're trying to find habitable zones in a large multidimensional space, in which we're forced to make regrettable, but necessary, trade-offs." —  Robert Smallshire"

The design envelope is multidimensional and we need to figure out what the dimensions of sensitivity are, what the thresholds are beyond which we fail, but which we may not even notice until we hit them.

The Trade-off Space Taxes our Bounded Rationality

That's a lot to bear in mind. Literally in mind. We all have mental models. They are all imperfect. And they are all different. But they are the basis for our decisions—consequential decisions; decisions we may not be able to back out of, especially as other decisions become layered upon, and even entangled with, them.

We need to "expose our mental models to the open air" (Donella Meadows), get them out where we can see them, and share, assess and improve them. Improve how we make decisions, by being more intentional about understanding the context, discerning what is relevant, and how.

Back to the Architecture of Architecture Decisions

So we have this composite structure for decisions, where the decision needs to be articulated in terms of the context, of the outcomes sought and the forces at play.

The contribution we make, is not just a good decision, but a decision that is good for its context.

Back to the Future of Our Past: Bringing Back Visual Design

Architecture Decisions are a defining focus of architectural design. (We need other views; that's for another post.) The architectural decision articulates how we will achieve the sought outcome, in light of the forces in the context that impinge on the outcome, and affect the consequences of design decisions. We need to decide on the design intention or outcome, how to achieve it, and investigate the impacts, the trade-off spaces, the risks. And we need to document this context with the decision, for it is what makes the decision make sense. Which also means we need to notice if the conditions expressed in the context change, indicating we need to revisit the decision.

Further, we're interested in how we will gauge, probe and monitor the effectiveness of these decisions, so that we can reverse them, or adapt, if they don't have the intended outcome. And discover this sooner, if we can. These are, after all, significant, high cost of change, make or break decisions. Progressive delivery of software to users is key, in that we can try things out with lower impact and back out of them if we need to. Still, we argue that sketching and modeling is a way to explore a design idea or decision, just enough, just in time, to get a better sense of design bets worth investing more in, by building the ideas out and deploying at least to some in our user base, to test more robustly. 

More on how visual design is something we need to bring back into our agile toolkit to help us think through architecting decisions and their impact, and to validate them before they are hard to change, in the full slides and notes (from which this post was extracted), here: Visual Design and Architecture

Footnote

* I highly recommend Alicia Juarrero's book, Dynamics in Action. Also, this twitter thread by Abeba Birhane is a wonderful companion reader, or refresher to those who've read Dynamics in Action a while ago.

The last section is stronger thanks to input from Jessica Kerr. (And if its still not strong enough, it's on me.) Jessica also amazingly pointed out that I had missed a slide -- a thing that is hard to do, when what you're noticing is the absence of something!