Visual Agility: Why We Model

Context for this Discussion

Design of complex systems is hard -- wickedly hard! It takes all the cognitive assist we can muster. Trade-offs must be made because there is interaction -- not just interaction among components to create a capability, but interaction among properties. And interaction between the system and its users and containing systems(-of-systems). And more! These systems are evolving -- the more agile, the more we try to take this co-evolution, this learning across boundaries, this symmathesy, into account.

This is responsive design, with an emphasis on responsive, and on design. Design in the classic Herbert Simon sense of design to make the system more the way we want it to be, more the way it ought to be. And responsive not just in the user interaction sense, but responsive to need, to changing understanding of need, and changing needs and contexts of use and operation.

That, after all, is what we mean by agility -- sensing change and responding adaptively. Responding to emerging or re-envisaged need, to opportunity or threat, and adapting. Adapting as the context shifts, and as we see opportunities to inventively combine and improve capabilities, innovating into the adjacent possible.

When we think of design in this way, as not just a learning process, but a co-learning process, it's clear that we want to learn in the cheapest medium that will produce learning that helps us resolve design direction, and the design decisions.

So let's revisit modeling, and why we should bring it back to the agile design table. I'm focusing here on architectural design (significant design decisions shaping how the system is built), but much of the discussion applies also to design of what the system is (what we'd usually call requirements). [Our orientation to architecture is that there needs to be interaction/co-learning not just across what the system is and its containing systems (or how it is used), but interaction between the design of what the system is and how it is built (to affect desired outcomes; what it is made of; interactions and emergent properties; etc.). But that is another story, for another day.]

We Model: To Observe

The point that I want to draw out here, is that of sketching to observe and attend more closely. And sketching not only to see structure, but to explore and discover or uncover relationships (that may be obscured in or even by the code), and to investigate system behaviors. Placing an emphasis on understanding mechanisms by considering which parts work in concert to achieve some capability (function and properties), and how they do so. Adjusting our point of view, seeing from other perspectives. Seeing to understand, looking for surprises, for contradictions that unseat our assumptions. Building our theory of design, and this design, and the relationships between contextual demands and forces and the design and its outcomes.

We Model: To Think

Designing is thinking. Hard! Reasoning, relating, making trade-offs. Architectural design is thinking across the system -- that's a lot to hold in mind. Visual thinking expands our mental capacity, and sketching these images and models expands our processing power still more. The mind’s eye is resourceful, but it can’t readily see what it’s missing. Sketching creates external memory, so we can hold more information and see relationships, make connections, spot inconsistencies and gaps, and draw inferences about causalities and consequences, highlighting what we need to exercise or test further.

Sure, code externalizes thought too. And code (and TDD) is an effective design medium. Still, models help us think through aspects like overall structure, or particular design challenges, even before we have (all the) code. We play out ideas in our imagination and on paper/whiteboard/screen, to define, refine, re-imagine, and redefine the dominant architectural challenges and figure out architectural strategies to address them, identifying where to do more focused experiments in code. This may sound like a lot, but architectural decisions are make or break, structurally or strategically significant, and key to design integrity. They warrant closer attention. Judgment factors.

Drawing views of our system, helps us notice the relationships between structure and dynamics, to reason about relationships that give rise to and boost or damp properties. We pan across views, or out to wider frames, taking in more of the system and what it does where and how and why (again, because we must make tradeoffs we need to weigh value/import and risk/consequences and side effects).

We Model: To Think Together

We draw diagrams or model (some aspect of the system) to think, alone, and to create a shared thoughtspace where we can think together (and across time) about the form and shape and flow of things, considering how-it-works both before we have code and when the very muchness of the code obfuscates and it is all too much to hold in our head, yet we need to think, explore, reason about interactions, cross-cutting concerns, how things work together, and such. [That long sentence reifies how soon too much becomes cognitively intractable.]

Now we have more minds actively engaged in coming up with alternatives, testing and challenging and improving the models. But also more shared understanding and common ground. At least, we're closer to a more reliably shared mental model of the system, with architectural views and maps to guide further design, and redesign (we're actively learning, if we're innovating), work.

We Model: To Test

Models help us try out or test our ideas -- in an exploratory way when they are just sketches, and thought experiments, where we "animate" the models in mind and in conversation. Just sketches, so less is invested. Less ego. Less time.

We sketch-prototype alternatives to try them out in the cheapest medium that fits what we're trying to understand and improve. We seek to probe, to learn, to verify the efficacy of the design elements we're considering, under multiple simultaneous demands. We acknowledge we can misperceive and deceive ourselves, and hold our work to scrutiny, seeing it from different perspectives, from different vantage points but also with different demands in mind. We consider and reconsider our design for fit to context, and to purpose. We evolve the design. We factor and refactor; we reify and elaborate. We test and evolve. We make trade-offs and judgment calls. We bring in others with fresh perspective to help us find flaws. We simulate. We figure out what to probe further, what to build and instrument. We bring what we can to bear, to best enable our judgment, given the concerns we're dealing with.

We humans are amazing; we invented and built all the tech we extend our capabilities with! And fallible; many failures, often costly, got us here, and we're still learning of and from unanticipated side-effects and consequences. Software is a highly cognitive substance with which to build systems on which people and organizations depend. So. We design-test our way, with different media and mediums to support, enhance, stress and reveal flaws in our thinking. Yes in code. But not only in code.

In the Cheapest Medium that Fits the Moment

Along the way -- early, and then more as fits the moment -- we're "ensemble modeling or "model storming" "out loud" "in pairs" or groups. And all that agile stuff. Just in the cheapest medium for the moment, because we need to explore options quick and dirty. Hack them -- with sketches/models, with mock-ups, with just-enough prototypes. Not just upfront, but whenever we have some exploring to do, that we can do more cheaply than running experiments by building out the ideas in code. We do that too. Of course. But! We have the option to use diagrams and models to see what we can't, or what is hard to see and reason about, with (just) code. Enough early. And enough along the way so that we course correct when we need to. So that we anticipate enough. So that we direct our attention to what is important to delve into and probe/test further. So that we put in infrastructure in good time. And avoid getting coupled to assumptions that cement the project into expectations that are honed for too narrow a customer need/group. And suchness.

In Sum, Then

When we, as a field, for the most part turned away from BDUF (big design upfront) toward Agile methods, we tended, unfortunately, to turn away from architecture visualization and modeling. We've argued here that sketching and modeling is indeed a way to be agile – to learn with the cheapest method that will uncover key issues, alternatives, and give us a better handle on our design approach. Not to do this as Big Modeling Upfront, but to have and apply our modeling skills early, to understand and shape strategic opportunity, and to set design direction for the system. And to return to modeling whenever that is the cheapest way to explore a design idea, 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. 

"Building software is an expensive way to learn*" -- Alistair Cockburn

Image Credit: Sketch by @Stuartliveart and Words by Alistair Cockburn (@TotherAlistair). Used with permission.

* Footnote: The more complete version includes: "How are you going to probe the world, don't just think through the problem?" along with "Building software is an expensive way to learn." It comes from Alistair Cockburn's "Heart of Agile" workshop, at the point where he is addressing probing and learning about the world the problem serves (like doing surveys).

In this post, I have borrowed "Building software is an expensive way to learn" into the architecture space to remind us to learn as cheaply as fits the design problem of the moment. This post uses "probe" in its dual sense -- (i) to explore (in this case, with our mind aided by sketches/diagrams/modeling tools) to understand/discover/investigate and (ii) to instrument to examine/learn. It addresses "how will we probe the world [of the technical design]?" with allusions to thought experiments, prototypes and building out design elements to more robustly test them, etc., but it would be useful to elaborate further in a post that focuses there. And then there's all the posts that could address the more broad design context (design of what the system is and is becoming, going beyond design of the system internals). But next, I think I'll address heuristics, again focused on architectural design.