What's This Then? A Trace? In the Sand?
This is a journal -- where I write traces or musing on topics I relate to architects architecting architecture. I have been doing this for 10 years!
To get an idea of what this Trace is like, here are some traces from February:
Visual Design: Sketches, Diagrams, Models
I offered to help Sebastian Baltes get word out about his study, because I think it is important to our field:
We want to learn more about how and why software practitioners use sketches and diagrams. If you regularly work on software projects and would like to share your experience with using sketches and diagrams in software development in a short interview (20-30 minutes), please feel free to contact (researchsbaltescom)
More at the Sketches and Diagrams in Practice project page.
Of course, I have written much on the topic. Here are some related traces (with some appeteaser quotes pulled out, so you know what you've been missing):
When are diagrams useful? [9/1/11]
Architecture sketches [8/9/07]
- when is it useful to engage the "right brain" (used loosely, as a signifier for holistic thinking, for example), or at least different thinking patterns, styles and mediums?
...sometimes it is good enough to simply conjure images in our mind's eye as we noodle. In our mind's eye it is easy and cheap to shift and reshape what and how we are viewing the problem, but for something we are having a hard time pinning down, drawing it out can help tremendously. Can, but our education in math and computer science/software engineering does not typically encourage us to, nor awake us to the fact that our visual processing machinery is very powerful and good at spotting anomalies, patterns, boundaries, relationships, and so forth. And we expand what we can manipulate at once, using paper (dead-tree or e-) as an extension to our short-term memory.
- what are diagrams or visual models good at?
When is it useful to create a shared "thought space" by externalizing our and other's thinking so we can collaborate more effectively on the kinds of problems that diagrams -- informal visual models -- help us address? When is it useful to be able to quickly and sketchily try out a number of alternatives, "testing" them by running through them with various stakeholders (as relevant)? When is it useful to have something other than code to help us communicate? And when is it useful to be able to abstract from the details of the code, to reflect on the state of things, to learn from what we've done, to improve structural integrity and to evolve the system?
Quoting Paul Gielens (original no longer available):
'What I did, and still do is to carry a sketchbook with me and draw models of the envisioned architecture solution when I explain it to stakeholders. I explicitly redraw the picture each time and validate my drawings with the stakeholder reaction. After having explained the solution a couple of times and gathering valuable feedback I learn how to communicate the architecture effectively. After a while you'll find your own preferred drawing style which is, along with your other competencies, a great tool to add to your "architect toolbox".'
with my commentary:
- explicitly redraw the picture each time: hand-drawn pictures have a "not done yet" feel to them, allowing for more interaction and a shared sense of ownership for improving the picture; it establishes a collaborative stance, and doesn't raise defensiveness
- validate my drawings with the stakeholder reaction: watch for cues from the stakeholder—body language and verbal feedback; a negative reaction, whether it is lack of understanding or disagreement, is a source of opportunity to improve—the drawing, or the solution, or the way I talk about it
- having explained the solution a couple of times and gathering valuable feedback: adapt and iterate, learn and improve
There are a gazillion traces linked under Visual Thinking and Visual Design on the Trace Map page (which goes through 2011 or so, with a smattering of additional traces).
I'll try to pull out a more representative selection... if this is helpful to anyone???
Also... of course, not to be missed:
Upcoming Open Enrollment Architecture Workshops
In a recent email (4/15/16):
"I’m told by the architects here, that attending Bredemeyer training is a must!"
More about what we do:
- Trace In the Sand Blog
- Bredemeyer Resources for Architects
- Software Architecture Workshop, Boston, MA,
June 27-30, 2016
- Enterprise Architexture Workshop, Chicago/Schaumburg, IL, July 18-21, 2016
- Journal Map
- storylines tubemap by Peter Bakker