A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

July 2014


What's a Trace?

My Trace is a playground for developing ideas, for exploring architecture and the role of architects. It is a journal of discovery, and traces my active reflection. I've been journaling "out loud" here for over eight years. To get a sense of the span, calibre and contribution of this body of work, there's a selection of traces linked here. When reading a trace in isolation, it may feel like you've been dropped into a thought fray unprepared for the action that is already in progress. It's okay. You're smart, and my Trace assumes that. You'll get your bearing quickly. Just give it a chance.

It is a journal. That is, it is an informal trace of wandering, exploration, discovery. The insights are there in their sparkling bucketfulls, but there are fewer clear onramps and offramps to and from them. ;-)

Sure. It may be difficult, textured, relying on emergence and recursive structures, polythematic, playing with delicate and intricate harmony sometimes, discordia others... So?

Shouldn't writing for smart people expect us to rise to the occasion of it? And this is an occasion! It is the writing of now, as it unfolds. It can feel unsteady, foggy. But in the clearings, how gorgeous it is! No?

No? Oh. Well. I try. speaker!


July?!? And Me, London, October!

Goodness me, June went by in a flash!

Well, whatever else happened in June, it was largely overshadowed by this kindness:

Legendary? Woohoo!


Richard was being playful and that kind of wry humor so works for me. Of course, if this field had the sense to be interested in what I do, I would be legendary, no?

No?!? Well. You're just no fun. :-)

Right then. If you are in Europe, it would be so frabjously awesome if you could join us for this workshop. And wherever you are, do tell others about it.

I insisted on the "different" framing of my speaker image because my workshops are very much like that -- about me not being the central figure, but rather creating space where we all contribute to building the experience together. I am forceful, but I apply that force to enacting and creating what I value. It's about inspiring and enabling, not dictating. I bring a lot of experience and insight -- and questions -- to the table, and so does everyone who participates. Let's do this!

Architecture and Design

Oh. And while we're allowing ourselves a rare moment of seeing Ruth in a kind, perhaps even overly generous, light, do please take a moment to relish my framing:

The arc of software architecture encompasses various considerations and decisions, resolving important sets of interacting tensions. Among them:

  • strategic and structural significance: identification of strategic outcomes and defining challenges; design of system capabilities and system structure; system qualities and mechanism design;
  • decision scope: decisions at broader scopes (system, mechanism, service) and decisions at narrow or local scopes (units) considering intentionality and emergence;
  • timing of decisions: clearing the fog of uncertainty/putting ground under the feet and the "last responsible moment", iteration and evolution

Puts all those characterizations/definitions of software architecture in their place, no? ;-)

<What is she getting at?>

I heard that. You know. It's not just "high cost of change" but strategic and structural significance.

While we're on one of those "would you just take a moment and marvel at what I did there" kicks, let's also revisit:


  • establishes (understands and ascertains what is relevant in) context,
  • understands and articulates/constructs intention (desired outcomes, capabilities and properties),
  • surfaces grounding assumptions, makes assertions (what we hold to be true) and projections (seeks out trends and shaping forces)
  • identifies challenges to be addressed
  • negotiates boundaries (negotiates/assigns shapingly significant roles/responsibilities, makes trade-offs across boundaries)
  • designs interaction surfaces and interactions across the boundaries to achieve the intention, and
  • addresses how the intention will be delivered (and associated challenges tackled) *messy

That is, for each design frame, we consider the chunk under design in more "black box" terms, considering its context or containing system, framing its intent (purpose, capabilities or responsibilities and properties or commitments to the containing system), boundaries and interactions across its boundaries, before -- and then iteratively as we learn more -- we get into the matter of designing the guts of the chunk.

Aaaand. As awesome as that is, and all that, it is also wrong. ;-) Well, wrong if you interpret it to mean hierarchical decomposition. There is some aspect of that, but (technical) wisdom applies, and design/technical wisdom has multiple facets. Among them, is insight into side-effects and action at a distance (spatial/organizational and in terms of time), with implications for priorities and significance, and timing and what needs to be tackled sooner and what can be deferred without undermining strategically significant outcomes. You know the refrain: Judgment factors. And factors and refactors. There is working different facets, there is back tracking, considering alternatives and trying different things out, there is sometimes working in the details, and sometimes drawing back out to design at larger scopes of impact, influence and interaction.

Aaaand. If that weren't enough. The very intention changes, as we learn what is possible and desirable. Sometimes more. Sometimes less. And in all this, we need to get ground under the feet, so to speak. Gain traction. Make something that provides value, makes a contribution.

Design ascertains what it is we want to accomplish, and how to do so, addressing the inherent challenges -- technical and non. It is not a linear process. It is not a do-once sort of thing. There is a lot of discovery -- the interaction of the thing with its containing system changes the containing system(s), and hence what we want from the thing. And hence it's inherent challenges. And so on. Messy. Mixing creativity and engineering, working towards creating value, but also engineered integrity -- structural integrity and resilience, adaptability and agility, sustainability. And design integrity, harmony. Even, where it matters, delight.

"To harmonize the whole is the task of art." -- Wassily Kandinsky

And architecture, as system (of system) design and art.

7/9/14: Delightful discussion of Feynman's delightful "There's Plenty of Room at the Bottom" speech:

"Standing alone in that auditorium, armed with no props or complex apparatus, Feynman would single-handedly pioneer nanotechnology—engineering at the microscopic level—a field that even now is considered to be at the forefront of human endeavor.


Feynman was clearly a dreamer, but he went about it in a very practical, business-like way. Once he suggested the possibility of writing Encyclopaedia Brittanica on the head of a pin, he immediately launched into some back-of-the-envelope calculations to establish  the feasibility of the task. He then asked almost reflexively, “Why not every book in the world?”

From there he was off and running.  How to write small?  Well, we can reverse the lenses of an electron microscope and write in the manner of a cathode ray oscilloscope, a common apparatus at the time. (In essence, that’s how microchips are etched today).  And if we can write books, why can’t we build tiny molecular machines?  (We now do just that).

Yet Feynman did not only see the possibilities, he saw the problems too.  Electron microscopes were not powerful enough at the time and there were theoretical limits to making them stronger.  Subatomic forces would create complications as well.  Undeterred, he conjured up potential workarounds for every obstacle, many which proved to be viable.

When you read Feynman’s talk, you get the feeling that he is not so much a physicist or an engineer, but an explorer.  Much like the famous biologist E.O. Wilson, he wanders around the nano-ecosystem, picking up objects of interest, examining them, figuring out where they fit and moving on."

-- Greg Satell, How A Genius Thinks, June 8, 2014

Reading that, I was thinking about something I read on the development of the iPod Touch, and how the innovation process is similar, from the point of view of coming up with questions and probing approaches. Sure, there are more big challenges and big unknowns with disruptive new technologies, but development of anything that pushes some frontier or other -- even just the complexity frontier of new features piled on legacy features -- has challenges and uncertainties, necessitating exploration of possibilities.

7/9/14: Thought provoking (thanks!):

While I do incline to characterizations of design as decisions (outcome: prescriptive/intention or enacted/actualized) or making decisions (process), I sense that the lines aren't so clear cut as Carlo is proposing.... that is, design can describe how something is intended to be structured and to work, or how it is structured and does work, without describing why it should be structured and work that way. That is, addressing "why" suggests a more explicit, reasoned decision process. We can -- arguably do, often -- design intuitively, making a myriad implicit decisions. For significant decisions, we want to make the rationale -- that why -- explicit, to weigh and resolve the design tensions better, and to better convey the decisions and how they were arrived at, but also to offer the reasoning -- what was taken into account, what tradeoffs where being considered in the design envelope, etc. -- not just to justify and connect the dots, but to encourage assessment and probing and improvement. As well as for conveying design savvy, mentoring others in the design process by making more of the design thinking, the considerations and the workable solutions and approaches, accessible to them. We externalize our designing thinking to advantage ourselves of various avenues of cognitive assistance -- memory enhancement (our working memory is limited) and reasoning tools like modeling and engineering tools from math to simulations and prototypes, reflection and conversations bringing various perspectives to bear, etc.

This is a useful observation and reminder:

'Parnas suggests hiding data structure details inside modules, but that was just an example. The real message was that modules should encapsulate decisions: every module [...] is characterized by its knowledge of a design decision which it hides from all others"; again: "we propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others".'

-- Carlo Pescio, Design, Structure, and Decisions

7/5/14: One of the awesome things about reading here, is that you get to be coached by Dana by proxy. Tonight he used the analogy of one DNA strand coming from "the business" and the other from "technology" to make up the solution. I like that image!

7/22/14: To which Paul Harland responded with a pointer to Spiral Dynamics -- thanks Paul.


Atypical -- in a Good Way? [And: Thanks for the Signal Boost!]

I love the insight cast in sparkling turn of phrase here:

"Sergio Leone wrings the cliches until diamonds drop from them." -- George Dinwidde

And I'd like to suggest that my trace is full of insight, some scooped up from others, but many wrung from (my own and others) experience and reflection. Each trace may seem like a playful and disrespectful waste of time... until you see the insights it tickles to dancing life.

7/3/14: Hey hey, Andy Collins joined Gene Hughson and Paul Harland in retweeting a link to my Trace today. (7/5/14: And Martin Howitt!)

7/5/14: Also. Many thanks to Amitai Schlair, Paul Harland, Stuart Boardman and Gene Hughson for amplifying my signal through the kindness of mentions and retweets. I am so grateful to them. (Yes, Peter Bakker, you too. :-) Love your photo stream, but I also wish you'd get back to tweeting and sharing where you look and what you see in the systems architecting and mapping/visualization space.)

peilcan diveSince these are people who have special powers of seeing, if you aren't following them, may I suggest you do? And since it is such a long way from the jubilant thanks a couple of traces up, I need to add: follow Richard West too, of course.

As for me, I have to resist every impulse to self-censor putting my Trace in a positive light. It is an unusual approach in any context, but especially so in a field that tends to the more formal in writing for our profession. This is ... highly informal and trace-y... Conversational, yes, but not just a conversation, no? That said, conversational and exploratory are important here. Participating in shaping the identity, self-concept and approaches of a field is important work, must be delicately done, in dialog with others, right? Anyway, my Trace needs someone to say "look, it may be different, but it is different in a good way, in a way that aligns with all the values we are professing. Values like collaboration and flexibility and openness to discovery and... Um. Failing." Hm. How'm I doing? Persuaded? I can self-promote in this little postage stamp lot on the i-Way? ;-)

Does that make sense? An unusual work has to be positioned positively, or people will overlook it, not knowing what they are looking at, or past. Because traces aren't designed to be structured nuggets, they are atypical and the casual glance is not going to uncover how powerful the style can be. It is powerful, isn't it? It lives its message, really -- design has to embrace being sketchy and informal and collaborative and dynamic, at times, even though, at others, it needs to be more rigorous and structured, achieving "industrial strength"... So isn't it good to also make allowance for embracing the messiness of the process that moves frontiers of understanding...? And isn't that what this Trace does?

Have I done rationalized this good? ;-) Well? Are you persuaded?

Image: went to fetch the dancer girl, and got to enjoy watching the pelicans fishing in Florida -- got lucky with some dive action shots too. If you think I'm fishing for compliments, you might enjoy the image. ;-)



Technical Debt, Extended

These snips are here to remind me that the conversation on extending the "debt" metaphor loosed some thunks to trace... when I get a moment...

Technical debt conversation, extended






I'm going to make another of those attempts at regrooving habits, and take a digital break. :-)




Accidental Rebellion

PLAYBOY: Do you think Lincoln wore his hair long to keep his head warm?

DYLAN: Actually, I think it was for medical reasons, which are none of my business. But I guess if you figure it out, you realize that all of one's hair surrounds and lays on the brain inside your head. Mathematically speaking, the more of it you can get out of your head, the better. People who want free minds sometimes overlook the fact that you have to have an uncluttered brain. Obviously, if you get your hair on the outside of your head, your brain will be a little more freer. But all this talk about long hair is just a trick. It's been thought up by men and women who look like cigars - the anti-happiness committee. They're all freeloaders and cops. You can tell who they are: They're always carrying calendars, guns or scissors. They're all trying to get into your quicksand. They think you've got something. I don't know why Abe Lincoln had long hair.



The Power of Pairing

"The lone-genius myth prevents us from grappling with a series of paradoxes about creative pairs: that distance doesn’t impede intimacy, and is often a crucial ingredient of it; that competition and collaboration are often entwined."

-- Joshua Wolf Shenk, The Power of Two: Finding the Essence of Innovation in Creative Pairs



The architect competency model includes consulting (mentoring and coaching, pairing to problem solve, etc.), which I think of as, in large degree, enabling others to be successful.

"The only thing to do with good advice is to pass it on. It is never of any use to oneself." -- Oscar Wilde

“It is better to give than receive- especially advice” -- Mark Twain



Growing Understandings

Gene Hughson's recent post on accidental architecture was prompted by an interaction that occurred when I tweeted a pointer to a trace on design and this quote from that trace:

Design is the act and the outcome. We design a system. The system has a design.

I wasn't meaning, by proximity, to suggest any direct and foregone connection between "we design" and "has a design" -- that is, I wasn't meaning to suggest I am not mindful of the incidence of accidental architecture; prompting that notion to emerge, was an accident of the structure. :-)

I was merely pointing to "design" having two substantial and different meanings (act, and outcome), which has implications for approach and medium (for example, are we seeking to support the act of designing, versus "seeing" the design in the built system). I illustrated the distinction with "design a system" (act) and "has a design" (outcome). Sure, this is the classic verb versus noun distinction that appears in the dictionary. The point was to rephrase in a way that helps us think about code as a design medium for the two different understandings of design -- design as act, versus understanding and communicating the design as built.

Of course, putting the two in close conjunction, does tend to prompt to mind the disjunction that occurs when system design is neglected, so that the system is pretty much a kludge of granular parts. In that case, the design may have been, for the most part, limited to design (thinking/acting/deciding) focused at narrow scope (like the scope of a class or function or some such narrower unit of abstraction and composition -- as opposed to system or "subsystem", etc.). That is, there is still design going on, but not explicit system-scoped design that contemplates and designs for system outcomes, such as system properties -- emergent properties that arise from interactions among the parts, not just the parts themselves -- and system integrity. We'd characterize the resulting architecture as accidental. And being accidental, it may not do a particularly good job of supporting some key intended outcomes; may even prevent them. This points to the importance of having a notion of design happening at different scopes of impact (ranging from unit to system) which gets us back to code as design medium -- while good as a local design medium, it doesn't particularly support reasoning about (all) system properties and resolving tensions and tradeoffs among them.

Anyway, what I was going after in the trace, was getting us to ask how well code supports design reasoning and expression. Clearly it does a great job of building systems, and a more or less sufficient job when it comes to design reasoning and expression given that it is often the limit, perhaps supplemented with a rough sketch or two, of the design tools we use to give ourselves some cognitive assist and to communicate and express our designs to others, not just the compute systems they run on. But relying solely on code and individual's mental models, means we lose some design information and we arguably don't give ourselves enough cognitive assistance given the complexity of our systems, and the myriad competing tensions and dimensions we need to weigh and resolve and better address. The F-35 is a case in point -- complex systems can't be approached as merely many, many "parts flying in formation, trying to be an airplane" (Wim Roelandts).

As growing understandings goes, Gene Hughson has been sharing concerns around mashing up microservices in cohorts to attempt systems in the absence of architectural design and understanding.

Michael Feathers comes at it from a different angle -- more a questioning and push-back on rampant complexity and scale. This is an important observation:

"When we break up big things into small pieces we invariably push the complexity to their interaction." -- mfeathers

Keep it small(ish).

Create concert among small.

What could possibly go wrong?

The matter of architecture. Resolving forces that stress the system.


Decision Scope

When I say "local" in the above, I'm distinguishing a locally focused design/decision scope like a class or function from more broad design/decision scope (like system). We use the "umbrella diagram" to talk about scopes, and scope ranges, depending on the system and what we are talking about. The scope of a design decision (set) may be a feature or capability. It may be a mechanism involving a collaboration of components or classes. It may be an algorithm. Or a class. Or a method.




I also write at:

- Bredemeyer Resources for  Architects

- Trace In the Sand Blog




Journal Archives

- Journal Map

- storylines tubemap by Peter Bakker



- January
- February
- March
- April

- May
- June
- Current


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


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



- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December


More Archives




I also write at:


- Strategy, Architecture and Agility: The Art of Change: Fractal and Emergent, 2010 

- Innovation and Agile Architecting: Getting Past ‘But’: Finding Opportunity and Making It Happen, 2008

- EA and Business Strategy: Enterprise Architecture as Strategic Differentiator, 2005

- The Role of the Architect:: What it Takes to be a Great Enterprise Architect, 2004


Ruth Malan has played a pioneering role in the software architecture field, helping to define architectures and the process by which they are created and evolved, and helping to shape the role of the software, systems and enterprise architect. She and Dana Bredemeyer created the Visual Architecting Process which emphasizes: architecting for agility, integrity and sustainability. Creating architectures that are good, right and successful, where good: technically sound; right: meets stakeholders goals and fits context and purpose; and successful: actually delivers strategic outcomes. Translating business strategy into technical strategy and leading the implementation of that strategy. Applying guiding principles like: the extraordinary moment principle; the minimalist architecture principle; and the connect the dots principle. Being agile. Creating options.

Feedback: I welcome input, discussion and feedback on any of the topics in this Trace in The Sand Journal, my blog, and the Resources for Architects website, or, for that matter, anything relevant to architects, architecting and architecture! I can be reached at

Restrictions on Use: If you wish to quote or paraphrase original work on this page, please properly acknowledge the source, with appropriate reference to this web page. Thank you.


- Links to tools and other resources



- Other Interests







Ruth by West

Copyright © 2013 by Ruth Malan
Page Created:July 1, 2013
Last Modified: July 28, 2014