Join us for free and read amazing contents on elCurator.

Get wind of our features.

Already registered? Sign in.

Why we model

Jul 02
0?e=2130105600&v=beta&t=bh1mvm0tjjetofkw nu9m9xqqbcagnkh8se0popgjmo
Sketch by @Stuartliveart and Words by Alistair Cockburn (@TotherAlistair)
    Published on

Ruth Malan

Follow Following Unfollow Ruth Malan

Sign in to follow this author

Architecture Consultant at Bredemeyer Consulting

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 context, 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, to 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 we should design across what the system is and how it is built, 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 the relation of structure to function and behavior. The emphasis on understanding mechanisms by considering which parts work in concert to achieve some function or capability, and how they do so. Seeing to understand, looking for surprises, for contradictions that unseat our assumptions, letting us see from a new perspective.

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 we can see the relationships, the connections, and we can reason about relationships, causalities and consequences.

Drawing views of our system, helps us notice the relationships between structure and function, 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. 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.

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 abstractions we're considering, under multiple simultaneous demands. 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 what we can to bear, to best enable our judgment, given the concerns we're dealing with.

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 "mob 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. Put in infrastructure in good time. 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.

Architecture Consultant at Bredemeyer Consulting

What are you waiting for? Get the best of the web.