A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

January 2016


What's This Then? A Trace? In the Sand?

This is where I keep a trace of thoughts on wanderings in the landscape of software and systems architecture and those that abut and have bearing on ours.

"As a writer, I love the irresponsibility of the short story...." --Tessa Hadley


Nearly 10 Years?!?

On February 3, this Trace will be 10 years old!

A few people are extremely generous in terms of giving exposure to my Trace through retweeting my links to it, or by mentioning it: Gene Hughson, Amitai Schlair, Paul Harland, Stuart Boardman, Cory Foy, Eugene Barker, Brenda Michelson, Vish Persaud and Ernest Buise have all been most kind. And Grady Booch, in addition to several retweets over the years, also links to my site from his Handbook of Software Architecture site! Other people who have been kind with retweets and mentions include Sally Bean, Andra Sonea, Mark Burgess, Marc Burgauer, Martin Howitt, Tom Graves, Arnon Rotem-Gal-Oz, JP de Vooght, Gernot Starke, Matthew Skelton, and Richard West. And recently, Matt McLarty and Mike Amundsen kindly mentioned my Conway's Law post and traces -- with enthusiasm even! And Uwe Friedrichsen mentioned my trace on empathy. Gratitude too, to a dear friend and a leading thinker in the software architecture space, Charlie Alfred. There are also a few people who have dropped off Twitter -- foremost Peter Bakker. [Update: He's back!! Yay! Great avatar!] And my long-time good friend, Daniel Stroe.

Time may change me
But I can't trace time
-- David Bowie, Changes


1/25/16: Thank you Michael (Geepaw) Hill! And Oliver Baier. And Marc Burgauer! After a mere 20 years, at least someone thinks of my name in relation to architecture! :)


Visual Design: Design Visualization

I tend to use visual design and design visualization interchangeably, and that's okay with me. :) But I also think it is worth separating, as follows:

Visual Design: where we use visual design expression to conceive, improve, and communicate our system design. That is, we are using visual expression (complemented by verbal and written descriptions, .., and code), to come up with, convey, and improve on our design intention. For emphasis: expression of design intention.

Design Visualization: where we express or reflect (facets of) the design of the realized/built system visually. This may or may not map to the design intention, as a myriad design decisions, and decisions that impact the design (at other scopes) are made consciously and unconsciously, wittingly and not, during coding. For emphasis: reflection of the design as realized (i.e., the as-built design, or the realized design).

In both cases, we are doing design -- we're seeking to make our systems more the way we want them to be (i.e., design, after Herbert Simon). And using visual expression to give ourselves a cognitive assist. Which we need, because our systems are complex, and hard to hold entirely in mind. If you see what I mean? You don't? I should draw it?

Art and architectureNow, Da Vinci did both visual design and design visualization in his sketchnotebooks. That is, he created new designs and designed inventions. And he expressed (key facets of) (existing) designs he saw, realized in the world, that interested him, to study them and communicate them. In the terminology I used in the talk/slidedeck/slidedoc, he used the iconic visual language he developed, to both express design intention, and to express realized (built) designs.

In our case, we very often use a quite different set of visual expressions for design intention and realized design. In part, this is because we direct tools at massive codebases to help us visualize what we can, by having an "objective" and exhaustive instrument (compute) extract design information. And this skews what we are looking for and at, towards what is computable. So-called "tribal knowledge" (in our heads and conversations, assumptions, etc.), for example, is not [yet? ;-)] computable.

“Emotions are not just the fuel that powers the psychological mechanism of a reasoning creature, they are parts, highly complex and messy parts, of this creature’s reasoning itself.” -- Martha Nussbaum

Update: Vish makes a nice distinction:

  • Visual Design: To be
  • Design Visualization: Is/as built

I don't want to bury the contribution under "it's obvious" -- expression of intention (and exploration as we conceive, modify and improve intention) differs from how we (using tools) reflect the design as built. What the talk (slidedeck) does, is lay out the landscape of visual design and design visualization, so we can see it, analyze it, improve what we get from it. The slides and slidedoc are valuable. But I can only say that so many times. At some point, someone else has to glimpse the value and say "ahhhh. Oh hey. This is useful!" Or something.


For those who can't read my scrawl -- put on your glasses! No, I mean, allow me to translate: our design expression creates a "shared hallucination" (we're being playful; bear with me) -- one in which the dream (design conception, which as we mature it, becomes design intention) informs/shapes and improves reality (double entendre of sorts there, because the system -- hopefully -- improves the broader reality by being in place, but the design hopefully also makes it a better system; better than it would have been if the design was entirely/more ad hoc and accidental). And, turning our attention to the lower return arrow: (our perception of) reality in turn prompts us to improve the dream (design conception/intention). But (focusing on the dream-dream arrow) the dream (design conception -- and its expression via sketches and descriptions, sketch prototypes; prototypes; code slices; etc.) is also an arena for learning and improving the design.


Data Visualizations 2015 Awards: analog wins one!

"By creating and sending the data visualizations using analogue instead of digital means, dear-data is what artists have done for ages, which is sketch and try to capture the essence of the life happening around them. However, as we are in the modern digital age, life also includes everything that is counted, computed, and measured."

1/16/15: With respect to features being visible, I do so resonate with this:

"Many good technology decisions, especially in infrastructure, show themselves as a system being almost invisible." -- Sam Kottler

I never said I was always right. ;) As designers, we (ideally) aim for systems that have natural affordances, and that don't obtrude into and obstruct or interfere with what users are trying to accomplish with the system. In getting at the architecture of a system, we're after perceiving the significant structures and their interrelationships, the emergent properties and mechanisms by which the system delivers its capabilities. That. But also the ideas, the reasoning, the intuitions, the constraints taken into account, and ignored, and so forth, that shape the system and lend it integrity or wholeness. To the extent that the system has integrity (design integrity, structural integrity, ...).

Push any idea far enough, and it wants to be a book. Or at least, a completed slidedoc. :)

1/25/16: Please note, though, that I think we really do need to keep design visualization open also to visualizing (future) designs/design improvements/design possibilities. That is, I like that design visualization as a term, contains both visual expression of design intent (or playing with intent, to better understand what we intend, or could make possible in the world) and visual expression of the design of the built system, to bring into focus some aspect(s) of the design as built/realized. That "ex-post observability" term JP deVooght used today. :)



Goodbye Josh

Reading the brief, but now so poignant, interaction between my daughter and my 15 year old nephew on Facebook as we were en route to South Africa... He died in a tragic accident the morning we got there. Everything. It all just breaks the heart! Some things are so unbearably hard! If we put our children in cotton wool and made them stay at home to be safe, we'd kill their spirits. If we let them out into the world, we risk having our hearts broken so bad! Josh was a beautiful person who took delight in, and gave such delight to us! I am so sad for his direct family. So sad for all of us who will miss his growing from teen to manhood. We have memories to treasure, but they also hurt!

Some girls from his school put bottles with messages in them, into the sea.

Life. Ours, those we love. It's fragile, and precious!


Software Architecture Workshop

Also, finalizing date for an Enterprise Architecture Workshop in April/May, working around client commitments.



Ecosystems -- and Architecture??

A trace by this title from back in 2012, began:

Why ecosystems? The term is being used so much of late it is sure to draw hype-antibodies and hype disillusionment... Yet, like Agile, beneath the hype there is something fundamentally important. So I'm not going to be intimidated away from what is important by the current overuse -- often incorrect use -- of the term, and instead focus on what I see being fundamental here. Architecture is all about primary, elemental, strategically and structurally significant shaping forces -- in the context, and the system under design(ed evolution). So the ecosystem -- the larger systems of interacting econo-socio-technical "organisms" -- is important to consider, as it shapes and is shaped by the system under design.

"Organisms" may sound a bit iffy. Let me back up. From an earlier trace:

James Moore's (pioneering) characterization of business ecosystem is important:

“An economic community supported by a foundation of interacting organizations and individuals—the organisms of the business world. The economic community produces goods and services of value to customers, who are themselves members of the ecosystem. The member organisms also include suppliers, lead producers, competitors, and other stakeholders. Over time, they coevolve their capabilities and roles, and tend to align themselves with the directions set by one or more central companies. Those companies holding leadership roles may change over time, but the function of ecosystem leader is valued by the community because it enables members to move toward shared visions to align their investments, and to find mutually supportive roles.” -- James F. Moore, The Death of Competition: Leadership & Strategy in the Age of Business Ecosystems. 1996.

This leverages the definition of (biological) ecosystem:

"A (biological) community of interacting organisms and their (physical) environment."

"Complex of living organisms, their physical environment, and all their interrelationships in a particular unit of space." -- Encyclopedia Britannica

Business ecosystems are not necessarily co-located even within a geographic region, but factors that drive and support the inter-relationships are what create cohesion within an identifiable ecosystem. The definition -- in terms of a complex or community of entities, their (inter)relationships, their environment and their relationship to it -- sounds familiar, huh? Not surprising though. Enterprises are systems-of-systems, and business ecosystems are systems-of-enterprises and other systems. Of course, these systems are more fluid, more organic and "messy" and porous and ... and adapting (holding in creative tension the desire to create stability and the desire to advance)... than mechanical systems. Those fall nearer the bottom of the hierarchy of our business ecology and we build them to gain greater leverage, control, precision and predictability over some aspect of activity.

That said, hopefully the Minecraft example helped a bit:

Consider a game like Minecraft and the ecosystem that has formed around it -- conferences, regalia, fan video series, server hosting for multi-player game play, creators of skins, mobs and mods, as well as communities of players, of course. By tolerating mods (and opening a Minecraft API up to other developers), the imaginations and work of a broad community is harnessed to extend the game, helping to set direction for the game but also creating a situation where more people have "skin in the game." That is, ecosystems can be thought of at different scales and scopes. Walmart is so powerful that it shapes ecosystems around its supply chain. Walmart and Minecraft would both be called keystones, relative to the ecosystem that depends upon them, even though the ecosystems are substantially different in economic size and formative impetus.

And... architecture? Oh, so now you want the notes to this slide?? ;-)



Well. Why didn't you say so?!

Something something Wardley Maps? Yes, and...!

"The mark of great leaders is the ability to understand the context in which they are operating and act accordingly." -- Nelson Mandela



Finding the Right Cleavage

That's a better title than "responsibility factors in design" or something responsibility-oriented like that? (Is propensity to "change together" conjoint with -- that is, the dual/flip side of -- responsibility-centered cohesion? In other words, does cleaving along lines of responsibility, tend to be the same as cleaving along lines of what changes together?) At any rate, it's a trace I ought to write, to explore that territory again. And a title I ought to use, as a Jester's joke? See if link clicks through to my site go up -- to like, ONE. Sheesh world. The high expectations the field has of (this) women in tech????

Well, at any rate, it's a chance to point to Cook Ting.

1/22/16: I don't even get to make it to the Imposter Syndrome base -- I have to fight the Low No Expectation Syndrome. So my inner rebel goes "what I did matters!" Which I suppose is better than feeling like I don't do important work... Silver linings by the playbook.


Not a Detour -- It IS the Tour

I opened with "This flight is going to Indiana by way of South Africa."

Sometimes, to get to where you're going, you have to go somewhere unexpected first -- because you don't know where "there" is, or why it matters.




How Hard Can It Be?

I mean, it must be hard, but... Okay so, the Visual Design slidedoc reports 2616 views, but slideshare analytics (available to the account holder) reports 682 views. That's... quite a big difference. And the latter is closer to right, given the links from Twitter as reported on tweets linking to the slidedeck (0 to maybe 3 clicks, for the most part).

Also, this happened -- buried down in a discussion thread, but still a nice little brush with positive feedback:






I also write at:

- Trace In the Sand Blog

- Bredemeyer Resources for  Architects


Architects Architecting Architecture'


Journal Archives

- Journal Map

- storylines tubemap by Peter Bakker



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



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


More Archives






My alter-ego:


Architecture astronaut





Copyright © 2015 by Ruth Malan
Page Created:October 21, 2015
Last Modified: February 1, 2016