a Trace in the Sand

by Ruth Malan

 

 

 

 

February 2019

2/8/19

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

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
Abstractions
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
cohesion
Gaps and improvements
Next guess
Refactor
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
Interfaces
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

Iterate
The end

 

 

to be continued...

 

 

 

 

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

 

2018

- Current

2017

- December

2016

- January
- February
- April
- May
- June

2015

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

2014

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

 

More Archives

 

 

 

 

 

Architecture astronaut

 

 

 

 


Copyright © 2019 by Ruth Malan
https://www.ruthmalan.com
Page Created: February 9, 2019
Last Modified: March 1, 2019