a Trace in the Sand

by Ruth Malan





February 2019


2019 OReilly Software Architecture Conference NYC: Visual Design and Architecture

[in process] Annotated Presentation Slides

Visual Design and Architecture Cover SLide


Part iii: Visual Design of System (Internals)

Note: This is a work-in-progress. More to come. If this is useful, saying so will help give impetus to this "continuous delivery" writing project :-)

System design is about coherence

System design is about coherence and integrity.

Architecrture is elements and relations

What Agile is Not

One way to understand or characterize what something is, is to characterize what it is not.

Not good architecture: entanhled
Dijkstra: keep it disentangled


Modularity matters

Architect's SCARS

Impatient for more? This post on SCARS may hold you over until I get to annotating this slide :-)

Follow natural structure
Finding abstractions
Starting point for guesses? System capabilities

Components guess

Here we have our first guess. We might note that the hand drawn,handwritten nature of it, is a feature not a bug. For hand drawn conveys incomplete, not done, still in-progress and changeable. It is humble, in the best sense. But given my writing, we can't read it, so...

Guess, redrawn
Gaps and improvements
Next guess
Parnas: start with decisions that are hard or likely to change
interactions with external systems susceptible to change
And the components
Cockburn's hexagonal
Steve Jobs: Design across

Posit structure, and play over the behavior

Design across structure and behavior and as do so, interfaces start to be flushed out

We generally advocate using just enough UML (or sysML) to get the job done. Where just enough may be UML-ish, if that's good enough. UML is a modeling language, and like other languages, its expressiveness is more than we generally need, support and convey our reasoning.

Use case and components
And with behiavor
Sequence diagram
Deployment diagram
Iterative and messy

Intention and reflection

Essentially my approach is that when we start out, we haven't decided what our elements are, even conceptually. We're just mucking about with ideas for how the system might be organized, toying with ideas for structures and mechanisms, and playing out how different alternatives might work, in as fuzzy and fudgy a way as suits the moment. But we start to tighten down our thinking as we make choices, and as our design thinking matures (meaning we make more decisions and the jell starts to be more viscous) we start to use more of the modeling power and more support from the tooling. As we build out capabilities (internal and user facing, prioritizing using judgment), it is useful to have support (in tooling) to show us the shape of the system and show us where the design in the code is departing from the architectural design so we can probe why and if this is a good thing, and so forth. Our tools must not become our masters.

Get feedback


Self-repairing egos
Donella Meadows: expose your mental models to the open air
Change your PoV
Marvin Minsky: understand it more than one way

Jerry Weinberg: three alternatives

Fred Brooks wrote "Plan to throw one away. You will, anyway." I'd say, that too, but plan to throw several away — on paper. It's quick and cheap. Use rich pictures, use case and component diagrams and play over behavior of interest — repeat. Do this at system level early to clarify direction worth taking/starting out in. But continue to do this (with just enough sketches and modeling focused on the concerns at hand) as challenges present themselves; some of these arise in the use context; some are internal “life sustaining” mechanisms that the system needs for it to be/become the kind of system it is (meet its persistence and dynamic data delivery/consistency needs; meet its scaling demands for spikes and growth; etc.). At any rate; "plan to throw some away," needs to include sketchprototypes. We need to try out alternatives in cheapest medium we can learn more in; sometimes that's code, but not if a sketch will do.

“If you haven’t considered more than one alternative, you’re not designing” — @stuarthalloway

The end



to be continued...


PDF here

Thank you to everyone for the mentions, likes and retweets and reshares on the various social media.



Workshop News

We have two open enrollment workshops coming up, one in the US and one in Europe. If you're interested in a Software Architecture Workshop elsewhere, do let us know. In particular, Dana Bredemeyer is looking at doing an Asia-Pacific "architecture tour" later in the year.

There's still space in both workshops:



About My Work


I also write at:

- Bredemeyer Resources for  Architects


Software Architecture Workshop:

- Dallas, TX, on April 29-May 2, 2019


Journal Archives

- Journal Map



- Current


- December


- January
- February
- April
- May
- June


- June
- July
- August
- September
- October
- November
- December


- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November


More Archives






Architecture astronaut





Copyright © 2019 by Ruth Malan
Page Created: February 9, 2019
Last Modified: April 1, 2019