A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

September 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.

What is my Trace like? Hm, let's see, I was reflecting on my early encounter with Twitter, and traced this:

Like my journal (oh dear, really?), it can feel a bit like some folks left their drapes open while they changed their minds...

Juicy tidbits aside... Back when (2/8/2013, if you must know), I traced these notes on "legacy":

I generally side-step the "legacy" term and simply ask: how long have the systems your business depends on, been around? The answer is always years (start-ups excepted), and always longer than people on those projects supposed, when the systems were first built. Then I draw (a variant of) this diagram:

strategy and architecture

And I observe that the systems are still around, because they deliver crucial business value.
Systems -- and their architectures -- enable and constrain the business. We have them, because they enable something we can't do without. But they also constrain what we can do, and how responsive we can be to opportunities in the market. And the deeper the inertial entanglement within the system, and of the system to past assumptions that no longer apply, the more miring the constraint. Constraints aren't necessarily bad; they focus and limit, but when the environment and hence desired outcomes shift, the constraints (ramifications of outdated intentions and entanglements) may no longer be adaptive and useful.
As terminology goes, I like to think of legacy systems as simply the systems we have in place -- they are the legacy of decisions and actions in the past bequeathed to us in the present, and they may be in good shape or bad. Ok, so they're typically in bad shape, or worse than we'd like, and worse over time. And too often without (adequate) tests that provide confidence in the state of the code, and allow us to make changes to it with confidence.

map of spaceAnd I borrowed from some of Conrad Aiken's legacy:

What did we build it for? Was it all a dream? . . . 
Ghostly above us in lamplight the towers gleam . . . 
And after a while they will fall to dust and rain; 
Or else we will tear them down with impatient hands; 
And hew rock out of the earth, and build them again.

-- Conrad Aiken, from The Dreamer of Dreams


So, you see, that's what my Trace is like. It is rather more like a journal or diary than the usual blog, in that it invites you to join an exploration in progress. Of course it is related, broadly speaking, to my interests in the areas that impact architects architecting architecture -- taking into account that our humanity as architects working in social contexts factors. If you want an idea of the mental map that organizes my thinking, you can scan the topic headings in my Trace map (it needs revision, but serves well enough to grok a level down from the organizing model sketched in the connected tubemap alongside).

Let it be noted. Reading here is a tolerance workout. And a tolerance for ambiguity workout. An empathy workout. And if you're training for like supergalactic missions, it's a great reading comprehension workout. ;-)


"The moment that code springs into being and is made manifest in a system, it becomes legacy." -- Grady Booch



Enterprise Architecture

So you know:

"Recently, ACM's Enterprise Architecture Tech Pack underwent a "refresh." Edited by James Lapalme, Assistant Director of the Numerix Research Laboratory at l’École (ÉTS) de technologie supérieure in Montreal, Canada, this expert reading list includes ACM Digital Library materials and key non-ACM readings.

The Enterprise Architecture Tech Pack provides perspectives and insights into Enterprise Architecture (EA), the fast-growing discipline and profession. Successful implementation of EA helps organizations respond to business needs and translate their vision and strategy into effective enterprise change. Although organizations are striving to be more effective in today's globally connected world, many have yet to achieve the benefits that EA can produce."

-- ACM email, 9/2/14

Tech Pack huh?



EA and Business Capabilities

Pioneering, landscape shaping work on EA as Business Capabilities Architecture:

How important was that work? Well, this -- from 2011, I believe -- will give you a sense of what a scene-setter our 2005 paper was:

Which should have you reaching eagerly for our 2010 paper, right? Things are speeding up, it should be hitting peak saliency soon. ;-)

Speaking of salience. We're getting several inquiries about and requests for our Architectural Leadership and Other Skills Workshop every week. So if you haven't read it, this paper may be of interest:


Shoes for the Cobbler's Children

Here are some pull-outs from a trace I wrote on code analysis and visualization (10/24/10):

What we need to be doing more, in the visualization space, is to ask: how can we help man and machine complement each other? That, I expect, will be (even) more productive than (only) saying "how can the machine do this for us?" or (more commonly) "what can the machine do for us?" Then we leverage the machine for what it is good at, and man for what she is good at. ;-) Partly, this is saying make the visualization/reflection game much more interactive, with the ability to compose conceptual structures that map to logical structures, for example.


Yes, the computer can trawl enormous datasets and extract data which we can organize into information and render in pleasing and/or informative ways (hopefully generally both, though simply pleasing is nice if we can afford it [insert wry smile here]). It can be more exhaustive, and uniformly/systematically created. Presumably this is, in some dimensions at least, more reliable, since human judgment and analysis is overlaid with perceptual biases and other fallibilities. How reliable, of course, may be a another matter of judgment or taste. So, how about pattern mining and sniffing out code smells...? How about assisting comprehension when coming on-board and having to understand an existing system that you are new to, or which is just too big to grok unassisted? These are among the applications of software visualization, of course.




London, October -- Be there!

Um. I mean. Be there?

I am sooo looking forward to working with so many great architects during the "Architecting: it’s (not) what you think" workshop at the Software Architect Conference in London (October 14)! We're already over the usual maximum for my workshops, and I'm thinking hard about where to cap it. So enroll soon if you want in!



From the Author Herself

INTERVIEWER: After you published your autobiographical memoir, Herself, in 1972 [...]

CALISHER: I’d been asked to collect my essays, criticism, and so forth. Their number surprised me, since I’d thought of myself as a fiction writer only. Perhaps because of that, their subjects were also very disparate. I found myself writing connective paragraphs to explain how I came to write them. Those became the book, essentially.

INTERVIEWER: And the title?

CALISHER: Changed to suit. I thought of it as a kind of reverse use of the Irish colloquial “himself” for “he.” Though Irish I am not. Herself is comfortably oblique. “I” and “me” can become oppressive. As a novelist learns.

INTERVIEWER: How do you mean?

CALISHER: To write in the first person seems the easiest. As all young journal-writers assume. Actually it may be hardest—there are so many hazards. Garrulity. Lack of shape, or proportion. Or even of judgment. On the other hand, when you’re really riding that horse well, it can feel as if you’re on Bucephalus. And you really feel the wind on you.

-- Hortense Calisher, The Art of Fiction No. 100 Interviewed by Allan Gurganus, Pamela McCorduck, Mona Simpson

Lack of shape. Proportion. Oh.

Oops. :-)



So C-Ute!

Nested tweets were made for this:

so bloody cute, eh?!

Epic cute? Sorry. I couldn't resist. :-)




Planting Seeds in the Earth of Life

"It’s part of maturity, to project upon your life goals and project upon your life realized dreams and a result that you want. It’s part of becoming whole … just like a childish game. It’s honest — it’s an honest game, because … you want your life to hold hope and possibility.

It’s just that, when you get to the real meat of life, is that life has its own rhythm and you cannot impose your own structure upon it — you have to listen to what it tells you, and you have to listen to what your path tells you. It’s not earth that you move with a tractor — life is not like that. Life is more like earth that you learn about and plant seeds in… It’s something you have to have a relationship with in order to experience — you can’t mold it — you can’t control it…"

-- Jeff Buckley


How to Use Conscious Purpose




9/27/14: Of course, the title of this trace is a reference to John Gall's wonderful essay (.pdf): "How to use conscious purpose without wrecking everything"



6. Locate responsibility in the system.

Look for the ways the system creates its own behavior. Do pay attention to the triggering events, the outside influences that bring forth one kind of behavior from the system rather than another. Sometimes those outside events can be controlled (as in reducing the pathogens in drinking water to keep down incidences of infectious disease.) But sometimes they can’t. And sometimes blaming or trying to control the outside influence blinds one to the easier task of increasing responsibility within the system. “Intrinsic responsibility” means that the system is designed to send feedback about the consequences of decision-making directly and quickly and compellingly to the decision-makers.

-- Donella Meadows, Dancing With Systems




Design of Design

Design of design


Look Ma, No Slides

Okay, so you know how we don't use slides in our workshops? See here:

no slides

Here's the link:

We do a lot of storytelling, but in training classes we mix in conceptual frameworks and techniques and such, so also use flipcharts. Binders full of studentnotes are provided as a safety net.


Conway's Law

Oh look, Conways Law


One of these days someone is going to make it cool to quote that Ruffyan creature, no? Smiles. Until then, I have to do this -- sorry.



Not a Token WiT. Right??

Well, well. Grady Booch kindly mentioned me in an InfoQ interview. It's a great interview -- not only is Grady generous in mentioning other people/their work, but he has a unique breadth and depth of experience and insight into the history, challenges and contributions of this field, and tells its story, lending historical perspective, vividly and compellingly.

9/15/14: Grady has led this field again and again, in various incarnations. Ada Components. Object-Oriented Design. Visual Design and leading the creation of a shared/common visual language to support visual design. Initiation of custodianship of a common visual design language (UML). Architecture. Cognitive Computing. Computing: the Human Experience and placing computing, and software in particular, in cultural and historical context, taking on hard topics like ethics and philosophy. And in that interview, he broke ranks again, and placed a woman deserving of the position, in the company of the Kruchtens, Fowlers, Becks and other men of our field. He again saw a shaping force in the trajectory of the software field that few were seeing. This time, it was me. Just kidding. Really. Not really. Well, mostly. Performance art. To make a point. Hyperbolically. ;-) I just wanted to offset any notion that it was just an affirmative action thing for Grady Booch to include me as the token WiT in his interview. ;-) High fives message the community. And we don't high five women. Or rarely. So. That was nice.

Thanks to J Fernandes for letting us know about the interview!

And thank you to those (Tony DaSilva, Gene Hughson, Mark Appleby, Stuart Boardman and Paul Harland) who so kindly retweeted my rather stunned and playful thanks to Grady:



White Men Arguing

arguing under cover

They missed some. But thankfully, little do they know...

  • Food Fight! [Alt: Design Wars: Part I: TDD kills System Design; PART II: A New Hero, the Daughter of TDD and System Design...], 5/3/14

9/13/14: Nice add to the TDD discussion.





This sort of thing:

working from negative expectations

is why this sort of thing:


is so very important!




Zanussi, Leading

We saw Krzysztof Zanussi's The Illumination and The Constant Factor. Zanussi himself introduced The Constant Factor, watched it with us, and addressed his own and audience questions after the screening. We were so privileged!! What a remarkable person!

The Illumination stands out as one of the top movies I've seen, both in terms of the immediate experience, and in terms of how it held and challenged my thinking for days and days after. The Constant Factor was superb, but it was missing something and I thought it was joy -- rapture in romantic love, joy in encounter (a sunrise, a beautiful mind, the ocean, the stars in mountain place...), the mind or the heart exploding open in passion. The woman-interest in the movie felt this too, and she explicitly said as much. But it was so small in the swirl of the movie, I'm not even sure if Zanussi really knew that what she was saying (in the film he wrote and directed) really summed up the whole movie! It is an awesome film. But without that aspect to life, our fate, the inevitability of it, is daunting and dooms the spirit. Both movies are from the point of view of a male protagonist, and women feature as a mother, a love, a wife. But not very much. A tenderness, real pain at death, but no entering into a rich communion, so little laughter and warmth and cracking open to another person. In The Illumination that was there, but one does have to look for it. Anyway, The Constant Factor, in particular, was lacking that source of remarkable connection, of collaborative making of Life -- with that big L. And sure, ultimately our experience is from the inside out, and can be a lonely quest, full of lonely adventures. But it makes me sad when there aren't those redeeming entanglements, physical, emotional and mindfull cracked-open-connecting with another whoman being (yes, who -- you know human, with a who in it; a distinct and vibrant who).

I wish I could see them again, and more of Zanussi's movies. But alas.

Except... A Year of the Quiet Sun.... And Foreign Body just premiered at the Toronto International Film Festival so maybe it will make it to arthouse movie theaters like IU Cinema... Hope hope.

Relevance. To architects, Ruth? To architects? Hell if I know. Wink. Well, you know. I'm on this trippy trip these days, thinking about the thinking that happens between. Like. When we read a book, or watch a movie, we learn from another person, from what they think and lead us to encounter. And we learn more what we think. There's all that the mix of cognitive fodder we've ingested has brought about in us, that now begins to react with this new work we're encountering as we metabolize its ideas and experiences.

Um. Relevance. To architects, Ruth? To architects? I'm getting there. Sheesh. Have patience would you. I'm figuring out what I think with my fingers dancing thoughts to view on this here lovely clicky keyboard I inherited from Ryan. :-) Oh. Okay, yes. Reward for the tolerant but hopefully also somewhat expectant reader who is still here, despite my feinting and faking. ;-) Well, a tumble-load of things.

One is that architecting is collaborative. If the designated architect does not treat it that way, if he is not collaborative, well.... is his design going to show up in the built system, or is the evolving system going to deviate from, accommodate and avoid and obviate the design at every turn? Some of that may even be intentional and malevolent disrespect and mutiny. But even if not, the built system will deviate from the design simply due to misunderstanding, misapprehension, circuiting and cross-circuiting to make progress despite the obstacles of the architecture, and so forth... the system will simply get rearchitected on the fly, to make it work...

Of course, collaboration can be hard -- all that thinking and working together, to work things out?!? Going it alone, grappling with tough challenges alone, not getting our thoughts all tangled up with another's, well that seems efficient and under our control, and we can draw hard lines on integrity, reason impassionately. Good stuff. Fun for brains. Safe for spirits. No drama of disagreements and having to persuade, to get another person to envisage the problems we're chewing on, or the solutions we're glimpsing and bringing into view. Ultimately architecture is important because the system is too complex for one person to just build. So there is the matter of shared understanding, of alignment on what integrity means for this system. Of what challenges are make or break, and need to be resolved in ways that don't break other things that are also strategically or structurally essential. And such... factors of architectural significance... Complex systems are hard, challenging, .... complex...

So, much as we introverts value our headspace and insularity, and much as we need to develop distinct points of view and values that are our design and human compasses, it is, it seems, essential to value the connection making. To lead, but also to be led. To influence, and to be influenced. And to have those moments of play. And joy, of thriving, in the defining-resolving-designing we do as architects working collaboratively -- out loud -- together, with others. There are so many ands to add here. And integrating others' ideas, and changing our mind when they have better, and creation of altogether new possibilities out of the generative process of more than one mind cogitating and metabolizing and synthesizing and understanding and....

It seems that the lone hero protagonist full of ideals and intelligent as all get out is missing something big about the human condition. Which is to escape the human condition. At least. to escape the insularity and time-space-boundedness of the human condition, if only in pinnacle moments. Moments where we create great masterpieces that transcend the individual -- his life, his only mind. That masterpiece may be a self. Imbued with richness by all the selves it has encountered and allowed to enter, this way or that, through cognitive or emotional connections. So even at that extremity of creation, the act is ultimately not as independent as we might suppose. And the masterpiece may be something we build in the world, together. Leading. Sometimes. Submitting to the ideas of another, at others. Challenging and reinventing each others' ideas, at others. A dance, sometimes even a tango. Sometimes improvised. Sometimes choreographed. Sometimes energetic. Sometimes... Acting on a deeply held sense that collaborative intelligence can be both more fun and fulfilling, and more productive of good, right, successful systems. Which you never asked me about. Well, your loss. :-)

Oh. Right. I did get a bit carried away there, didn't I?

9/18/14: But The Constant Factor is an exploration of integrity, and that is architecturally significant. Yesterday I listened to a David Woods lecture -- well, two. Awesomesauce. (He works on failure and resilience. 'nuff said, right?)

9/30/14: Neat Freudian slip -- I meant to write collective intelligence but my fingers knew better, and it came out as collaborative intelligence! But I like Elon Musk's "we need to strive for greater collective enlightenment" still more!




Naming Things and the Evolution of Meaning in Design

I'm so glad we have Dijkstra's essays! His observations speak eloquently; many are, if anything, even more pertinent today:

'When the design is complete one must be able to talk meaningfully about it, but the final design may very well be something of a structure never talked about before. So the design team must invent its own language to talk about it, it must discover the illuminating concepts and invent good names for them. But it cannot wait to do so until the design is complete, for it needs the language in the act of designing! It is the old problem of the hen and the egg. I know of only one way of escaping from that infinite regress: invent the language that you seem to need, somewhat loosely wherever you aren't quite sure, and test its adequacy by trying to use it, for from their usage the new words will get their meaning.

Let me give you one example. in the first half of the sixties I designed as a part of a multiprogramming system a subsystem whose function it was to abstract from the difference between primary and secondary store: the unit in which information was to be shuffled between storage level was called "a page". When we studied our first design, it turned out that we could regard that only as a first approximation, because efficiency considerations forced us to give a subset of the pages in primary store a special status. We called them "holy pages", the idea being that, the presence of a holy page in primary store being guaranteed, access to them could be speeded up. Was this a good idea? We had to define "holy pages" in such a way that we could prove that their number would be bounded. Eventually we came up with a very precise definition which pages would be holy that satisfied all our logic and efficiency requirements, but all during these discussions the notion "holy" only slowly developed into something precise and useful. Originally, for instance, I remember that "holiness" was a boolean attribute: a page was holy or not. Eventually pages turned out to have a "holiness counter", and the original boolean attribute became the question whether the holiness counter was positive or not.

If during these discussions a stranger would have entered our room and would have listened to us for fifteen minutes, he would have made the remark "I don't believe that you know what you are talking about." Our answer would have been "Yes, you are right, and that is exactly why we are talking: we are trying to discover about precisely what we should be talking."'

-- E W Dijkstra, "Why is software so expensive?" An explanation to the hardware designer.

This, too, from a bit further on, is an insight we maybe somewhat lost sight of, for a while, in OOAD zeal:

"the new syntactic categories were exemplary for the concepts that have to be invented all the way long, concepts that are meaningless with respect to the original problem statement, but indispensable for the understanding of the solution" -- E W Dijkstra, "Why is software so expensive?" An explanation to the hardware designer.

The domain is a source of analogies to leverage as we address the challenges of concept formulation and mechanism design, but not the only one.


All This is Well Known

Dijsktra would so fit in today --- he characteristically minces no words on (the topic of) managers:

'But apparently, many managers create havoc by discouraging thinking and urging their subordinates to "produce" code. Later they complain that 80 percent of their labour force is tied up with "program maintenance", and blame software technology for that sorry state of affairs, instead of themselves. So much for the poor software manager. (All this is well-known, but occasionally needs to be said again.)'

It hurts me to see how much we're still in that "us versus them" space when it comes to managers. If managers don't understand, we need to own it. We need to lead managers better, partner better, expect more from and enable them better. Sheesh. :-)

9/30/14: This is worthwhile for growing empathy and respect for managers, but also for growing appreciation for the "soft skills" and leadership side of the architect role:


Fractal and Emergent

tl;dr of our Fractal and Emergent paper:

Context: Players in ecosystems form networks of relationships that enable value transformations and flows. Their evolution in concert, allows periods of relative stability, which in turn allows for greater diversification and niche proliferation. However, disruptors reshape the ecosystem, so savvy incumbents don't spend all their resources on ecosystem enrichment and value transformation/extraction. They seek also to disrupt, though this is hard to accomplish -- you're no doubt familiar with The Innovator's Dilemma, which is renowned for capturing the dynamic. At any rate, this means that different parts of large organizations are concurrently participating in various ecosystems, at different stages in the ecosystem lifecycle, and these present different challenges for the organization.

Intentionality and Emergence: A fractal approach to strategy (and architecture), allows that organizational intentionality doesn't have to follow a top-down hierarchical control system model, but can be more organic and fractal. If all intentionality is pushed to individuals and small collectives in the organization, then strategy and design is emergent. But between top-down control and full emergence, there are many blends and hybrids, hence "fractal and emergent." Depending on the ecosystem, and the stage of the ecosystem, different blends of fractal and emergent strategy setting, and tandem architecture, may be more adaptive/have better fit to context and to purpose (value transformations and value exchanges).

And some other stuff. About architecture and architects.

9/30/14: And this is interesting:

Ah yes, Jim references the Constructal Law. Oh, you know, from Design in Nature. Which reminds me... I only got half way through that.

Books. These days. Too many get so ponderous and repetitively grind their mislabeled axes. ;-)

What's that? I feint? It means that I find Design in Nature provocative in that good thought stimulating way, but I'm deeply suspicious of dismissive styles because there is one thing I have learned and that is how easy it is to fool oneself when one is dismissive. Hence. I must return to Design in Nature. ;-)


9/30/14: Going, going, ......

That's the cool thing about clean slating at the turn of every month :-)

Well. So much for September.


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
- July
- August
- 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

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: May 1, 2015