A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

October 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 -- maybe a little September? or August? August was more chunky. September, somewhat spunky. Like this:

Books. These days. Too many get so ponderous, and repetitively grind their mislabeled axes.


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

Not that August was without -- I mean, who else titles a post about the Single Responsibility Principle

A Conjecture and a Knock-Down Argument... were taking a hike...

Oh, ello October:

Sure. Code wins arguments. But are all arguments worth having?

One day someone will notice that I do stuff like that, huh? But what about the content? Take the Object Synonymous trace. It's an unassuming, playful little trace that carries more than its weight in big ideas.

Oh yeah. This is worth digging up again:

... this clearly is a rather something body of work --- buried in our field, no less... Ah. The intrigue. The misdeeds. Buried? In a field?

Smile! Or. Smile?

Oh, well... at least the writing here is... energetic... and certainly does not stop at clarity and logic:

"Good writing is clear. Talented writing is energetic. Good writing avoids errors. Talented writing makes things happen in the reader’s mind — vividly, forcefully — that good writing, which stops with clarity and logic, doesn’t." -- Samuel Delaney

Last month, the balloon that lofts my ego high enough to write out loud in public, was punctured with criticism of my writing, so indulge me a little and at least give me energetic, okay? Thank you. You're very kind.

"To snare a sensibility in words, especially one that is alive and powerful, one must be tentative and nimble" -- Susan Sontag



London -- ARE. YOU. READY?!

I am sooo looking forward to working with many great architects during the "Architecting: it’s (not) what you think" workshop at the Software Architect Conference in London (October 14)! Gulp -- impressed that the workshop filled so quickly.

“Most people aren’t trained to want to face the process of re-understanding a subject they already know. One must obtain not just literacy, but deep involvement and re-understanding.” ― Charles Eames



'Splainin' Splainin'

My take on 'splainin' is that we are wired to connect, to help, to be collaborative and yadda good stuff. Sara wrote an awesome poem on oxytocin for homework last night (the wonder of deadlines, you know), and she won't let me have it to share with you, but here are the last two lines:

Oxytocin has grasp of our chemical soul
And honestly I don't mind it having control

Given all the other ways we're wired -- fight or flight lizard brain defense routines, and all that -- I'm all like "Moar oxytocin! Moar oxytocin!" Go look at photos of your kids when they were bubs.

But splutter. Splainin Ruth. You were splainin. Yeah. Yeah. I'm just preparing the ground of your mind a little, ya know. Take another look at those baby pics; gaze into the smiling face of your loyal and loving wonder-dog.... ;-)

So. Take wanting to help, and expectation biases, and voila. Condescension. We offer help to the stereotyped image of a person we hold, instead of investigating whether that help is even in the ballpark of being helpful, or if, because it bespeaks a view of the person that diminishes their abilities, it is an insult that says in actions what hurts louder than words.

Anyway. That's how I mom-splained 'splainin' to my teen when she came home hurt and rebellious at her first experience of this lubbly phenomenon. She took my 'splainin zeal in stride, and didn't let it dent her dignity, so far as I'm aware. I hope you're as tolerant. :-) The thing is, 'splainin is fine most of the time. It might be boring and tiresome, but not necessarily hurtful. It's just when it hits the core identity of a person that it really pins one to the wall in pain. Splain some obvious tech concept to a sparkle-bright nerdy girl based on small-minded assumptions about girls, and it's going to hurt. Because the assumption hurts. That sort of thing.

We want to help. And out of good intentions but misplaced projections of social legacy, we rush in to offer help before observing and orienting to whether any help, or that help, is needed.

Well. You knew that, huh? Oops. Well. Then. You know how this works. Again.

Observe. Empathize. Orient. And act on that impulse to help, if it serves well. Or if at least, we think, putting stereotypes aside, it will. For helping is important. It is social glue. It is how we do big things. Together.

Insert rah rah cheerleader stuff. I have to go finish invoices. I love doing the work. Invoicing not so much. Well. Not at all.

10/2/14: Saints alive - this!!


A Thin Veneer

Werner HerzogI tweeted an exaggeratedly child-like teasingly-playful pointer to the trace above. If you don't understand that play gestures are of survival value to those who would otherwise be ripped to shreds by the fringe guard of the pack... see the sequence around minute 1:30 of Stuart Brown's talk on play. ;-) But it's complex. And complected. Emerging as we do from chemicals and culture and ... Also

"Civilization is like a thin layer of ice upon a deep ocean of chaos and darkness." -- Werner Herzog

Also also. Sara's poem is extraordinarily sophisticated -- in the meaning it affords directly and by allowance for attachment of new associations and emergence of new meanings, besides those she intended. It contains an astonishing insight into biochemistry, (neuro)psychology, philosophy, poetry, and more. Where I'm not using astonishing in an age context, but in the context of the state of our collective enlightenment and individual sensibilities.

Text snip right: from Werner Herzog - A Guide for the Perplexed: Conversations with Paul Cronin By Paul Cronin

Thank Heavens for oxytocin! And collaboration, co-creation, culture, ... . :-)


Text -- to weave

We are social animals, and we respond to "religions" that bind. Tech tribes. Science-ism. ;-) Atheism. And the religions we've called religions, that have various aspects (spiritual not the least), including, importantly, the social identity and relationships that nurture and support.

What's that? No, I'm not going to talk about sexuality next. Goodness! (Insert mock horror here.) But... when I have a moment, I'll share how remantic love and fiction came up in a workshop recently... I sure hope people didn't think I put the two together! I don't read slop-romance, so wouldn't ever conceive of recommending it! ... Oh yeah. Now you're interested?

PS. If you're not following David Troupes you are missing out on following the genius behind Buttercup Festival -- and an awesome word poet too. His Renaming of the Birds is wonderful. We need to care more. blog blogAs a powerful poet of the ecology within and without, David's work fuels that caring. Anyway, David has this great way of connecting what is going on in nature, and our interactions with nature, with our humanity -- how nature (including human nature) impacts us, how we impact the innocent, generous natural world. In BF and in his word poetry, he can knock you off your feet with the gentlest touch.

"We’ve lost 52 percent the planet’s wildlife in the past 40 years" -- Enchanting Photos of Rare and Wonderful Frogs and Salamanders


Both of Me

If you don't follow both of me, you're missing half the fun:



I had to invent someone, to have someone to talk to at the twitter water cooler. ;-)

Oh. Right. Invoices.

And. That workshop in London. That I am eminently prepared for. And not.


walk two moonsI'm kidding about someone to talk to. Still. I miss Peter Bakker. We're each busy with our own agendas, our self-interested navel-gazing, but we inform and extend and, yes, even co-create each other. I hope Peter comes back to share his next path of discovery on Twitter! He dives deep, and I enjoy where he takes us. I've "met" several awesome people on twitter, and it's important because client work whirls one through people's lives in bursts. Peter made me welcome on twitter and was my bestest friend there for several years.

As navel-gazing and "other things I write" goes, I like how this one uses an image that intrigue-attracts and surprise-repulses:

We're so wrapped up in the lint from our own navel, we can't see the good in others

Shock therapy. Smiles!


So. Movie version of the book, huh? When that was said, it was, I think, with that double sense. A movie is its own thing, but it doesn't replace the book. And neither replace the living-experiencing of life and what we learn there-from. But I have been tempted to tell people at the end of workshops that what we have just done is a head-fake (in that Randy Pausch sense). We think we're drafting an architecture, but what we're really prototyping is the next version of ourselves as an architect.

Nothing worth missing in this Trace. Nothing! You just might not know how to make use of it all. But there's nothing worth missing. Trust me. ;-)

Trust. Now there's a thing. Those who read here -- thank you! Trust is an amazing gift, but also to the giver. For it makes things possible.

Nothing worth missing? Even that thing about working on invoices? That was a bridge. Bridges are important.

This. You guys! This!!



I hope someone does something like this during my workshop in London:


I give people notebooks with blank pages. Do you think I need to start workshops with a quick intro to sketchnoting? Well, right after I do a quick intro to storytelling, by telling and debriefing a story. ;-)


Pair of Ducks and Other Things Duck Soup

When I saw this:

"Big jobs usually go to the men who prove their ability to outgrow small ones." - Theodore Roosevelt

I thought of:

"The Peter Principle is a concept in management theory in which the selection of a candidate for a position is based on the candidate's performance in his or her current role rather than on abilities relevant to the intended role. Thus, employees only stop being promoted once they can no longer perform effectively, and "managers rise to the level of their incompetence." Peter principle The principle is named after Laurence J. Peter who co-authored with Raymond Hull the humorous 1969 book The Peter Principle: Why Things Always Go Wrong." -- wikipedia


"The reward for doing good work is more work. Do a great job at work and you’ll be rewarded with more projects. Do a poor job and you’ll get less work. Be agreeable and people will ask you to do more. Be difficult and disagreeable and people will leave you alone. [1]

This is related to the Peter Principle: When you do a great job at something, you tend to get promoted. If you do well at that job, you get promoted again. Eventually you will reach a job where you are unable to perform well, at which point you will no longer be promoted and will remain in that position indefinitely. The net effect is that managers rise to their level of incompetence."

-- Dave Gray, The paradoxes of organization

Which brings us to:

"A complex system that works is invariably found to have evolved from a simple system that works." -- John Gall (Systemantics)


"The Peter Principle is a special case of a ubiquitous observation: Anything that works will be used in progressively more challenging applications until it fails." -- wikipedia


And of course, no duck soup would be complete without:

The politician's syllogism, also known as the politician's logic or the politician's fallacy, is a logical fallacy of the form:
We must do something
This is something
Therefore, we must do this.

-- wikipedia (via mfeathers)

"All of my creation is an effort to weave a web of connection with the world: I am always weaving it because it was once broken." -- Anaïs Nin


Conway's Law


"Organizations for a few years now have understood this link between organizational structure and software they create, and have been embracing new structures in order to achieve the outcome they want. Netflix and Amazon for example structure themselves around multiple small teams, each one with responsibility for a small part of the overall system. These independent teams can own the whole lifecycle of the services they create, affording them a greater degree of autonomy than is possible for larger teams with more monolithic codebases. These services with their independent concerns can change and evolve separately from one another, resulting in the ability to deliver changes to production faster. If these organizations had adopted larger team sizes, the larger monolithic systems that would have emerged would not have given them the same ability to experiment, adapt, and ultimately keep their customers happy."

-- Sam Newman, Demystifying Conway's Law

And some links:

Microservices and Conway’s Law interact. If the system is composed of small-grained independently deployable “slices” of functionality, you can have small multi-functional teams assigned to features (or feature-sets) or capabilities or tightly related collections of user stories or however you'd naming the ("vertical") chunks of functionality. Good stuff. Except that without architecture, there will tend to be duplication and inconsistency and integration/choreography (and potentially, for large systems, findability) issues. So architecting ACROSS microservices is STILL important – or more important. Does that make sense? Conway's Law effects mean there will tend to be stronger boundaries at the team boundaries, and microservices will create visibility barriers around the team=microservice boundary, unless something explicit is done to accommodate for that communication boundary.

"strong ties, breeding local cohesion, lead to overall fragmentation" -- Mark Granovetter, The Strength of Weak Ties



SRP and Code Wins Arguments

For many in software, there is the sense that unless something is described with code, it didn't happen. Of course, we have to abstract away from that specific code to get to the generalized principle. I go for the principle. I expect facility with the translation just as a poet expects facility in a different domain. Abstraction is not just a one way process.

But for those who found my

and the follow-on

traces too abstract, or just want a different view to prompt further reflection and knock insights into focus, here is Cory Foy's (independent*) take:

There was also:


* With very, very few exceptions, people don't read here. There's the matter of attention overload. And, with rare exceptions (this Grady Booch interview for example), no-one is going to say my writing is worthwhile. Well, I'm grateful that there have been a few exceptions! And at this point I'm happy to fly under the radar, being, as I am, a fallible creature, and all that. :-)

Highlight of 2013: Somebody said '"Trace in the sand" is like poetry to me, which is why I can enjoy even the parts I don't understand'



Yak Shaving with Occam's Razor

Yak shaving with Occam's razor



It's Not What You Think

I didn't get my passport back in time -- my fault as I didn't give the visa process enough time. I was hopeful that with expediting it would work out, but alas, it takes on average 15 working days plus biometrics that have to be done in person by appointment, so even more lead time... Well, Plan B -- Dana teaching the workshop -- is an awesome backup. Needless to say, tears spilt and way stress. The increasing levels of lack of trust in the world sure has its costs. I understand, there are abuses of trust and its a more dangerous world in some ways. But still. Well, it is a reminder to appreciate where we can operate in spheres of higher trust -- bring that Speed of Trust thing to bear where we can.

10/14/14: Whoo-hoo:

The abilout guy was wonderful :-)

Somebody (very gently) suggested that I self-sabotaged, asking if I have imposter syndrome. No, no. Well, I don't think so. I mean, the subconscious is a very weird and strange place, but I was so excited! There were at least twice as many architects as I usually work with in a workshop, but I arranged a mic. And a day goes by so quickly (we usually do 4 or 5 days), but I prepped for that. I'm confident that I have much to offer in areas that are valuable to architects. That's what I do, what I give my life into. I know I have weaknesses; everyone does! But I have strengths too, and my strengths are complementary and, I am given to believe, helpful to those I work with. So I feel confident and resourceful -- in that "has her resources at her disposal" kind of way that applies when a person feels competent and up to the task at hand. Oh, I rely a lot on the architects working with me, but it's not about me, is it? It is about a useful experience, and people have to vest themselves in experiences to get the most out of them. One can't pipe knowledge from one person to another, at least not yet. :-)

At any rate, the title was self-fulfilling. ;-) It's not what you think. Indeed. It would have been wonderful to be presenting at the conference and to have done so on Ada Lovelace Day. There was such a great show of support in the enrollments too! But my words get out into the wilds through my writing, and Dana is kept so booked by clients that at least there was this opportunity for more people to get a chance to work with him. So. That's goodful. If you have to go to Plan B, it is good if it is an upgrade. :-)

If you don't already follow Robert Smallshire, get on it! :-) Dana enjoyed meeting and getting to work with him today. Ah well, there's always the future, huh?

10/16/14: That said. The subconscious is a weird place. What we are paying attention to shapes what we perceive and pay attention to. We can be so focused on counting passes, we don't see the gorilla. And all that.

We watched 12 Angry Men last night -- so much rain this past week, it was indoor workout time. Now that is a movie every architect should watch (again)! Daniel Kahneman got the Nobel Prize in Economics in 2002, but 12 Angry Men did a superb job with our fallible perception and psychology of judgment -- in 1957!!!


No buts. We have to persuade Sara to let me share her latest recording with you. It is frabjously AWESOME!! It's addictively lovely, and has magnificent poetry, like this:

Carry bad days past their borders

Silver lining? I'm now good for multiple entries to the UK over the next 6 months. Any conferences coming up? Sigh.



Big Context, Little Context, System

Russell Ackoff urged that to design a system, it must be seen in the context of the larger system of which it is part. Any system functions in a larger system (various larger systems, for that matter), and the boundaries of the system -- its interaction surfaces and the capabilities it offers -- are design negotiations. That is, they entail making decisions with trade-off spaces, with implications and consequences for the system and its containing system of systems. The system changes its containing systems, and we can do so with intentionality (design, experiment, learn, redesign) to get more what those who are imapcted, want. We must architect across the boundaries, not just up to the boundaries. If we don't, we naively accept some conception of the system boundary and the consequent constraints both on the system and on its containing systems (of systems) will become clear later. But by then much of the cast will have set. Relationships and expectations, dependencies and interdependencies will create inertia. Costs of change will be higher, perhaps too high.

Here is Charles Eames' sketch of Charles and Ray Eames' design process:


Image source: Statement of the Eames Design Process

Charles Eames said "The details are not the details. They make the design." He also said "Recognizing the need is the primary condition for design." So there is this process of zooming out to see the bigger context (where the needs, but also key challenges and constraints, lie), and zooming in to the details. The Powers of Ten film by Charles and Ray Eames is well worth (re)watching.

The schematic below is an over-simplification, but it is intended to simply highlight the importance of not just viewing the system in deployment and use contexts, but also zooming out to the "tantalizingly almost relevant" (Bucky Fuller) broader ecosystem context.

Context within context


I put requirements in air quotes in the schematic, because requirements are a design negotiation -- we may take requirements to be givens, but then we are falling into the trap of (arbitrarily?) making them given. Oh, I know, in contracting situations, the requirements are given. Right? This video -- The Expert -- did the rounds, so you probably saw it, but it is also worth (re)watching. Sure, it is hyperbole turned all the way up to hyperbolic, but it gets the point across. Gratingly. Admirably so!!

I'll get to more, but in the meantime, here is your periodic reminder to take a look at The Art of Change: Fractal and Emergent. Along with Getting Past ‘But’. Yeah, yeah. They are products of their time, but also ahead of their time and highly relevant still.


12/7/14: We can't do it all, all at once, all ourselves, so the moment matters:

What at this extraordinary moment is the most important thing for me to be thinking about?

The "extraordinary moment" principle is a handy tool -- an Archimedes lever if you will. The architect, as leader, needs to lift her head from the tactical grind and consider what is make or break -- what is architecturally significant -- and how best to do that (and when).

Playing Nice

Postel’s Law, otherwise known as the robustness principle, is a general design guideline for software:

Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept"). -- wikipedia

Postel’s Law could be called the “Play Nice principle.” See, for example, Martin Fowler's TolerantReader writeup. More in this trace.

The architect needs to think of various ways to “play nice” – not just interactions under current demands, but also thinking about backwards and forwards compatibility. Here's a topical example:

"The version of Windows following 8.1 will be Windows 10, not Windows 9. Apparently this is because Microsoft knows that a lot of software naively looks at the first digit of the version number, concluding that it must be Windows 95 or Windows 98 if it starts with 9. Many think this is stupid. They say that Microsoft should call the next version Windows 9, and if somebody’s dumb code breaks, it’s their own fault. People who think that way aren’t billionaires. Microsoft got where it is, in part, because they have enough business savvy to take responsibility for problems that are not their fault but that would be perceived as being their fault." -- John Cook

Here is the backstory on reddit.

I really like "The responsibility of architecture is the architecture of responsibility" (Jan Van Til, riffing off Tom Graves). It isn't complete, but it sure is important!

There is no avoiding responsibility. Thank you mfeathers.


Software Architecture: It is (not) what you think

In what follows, the caps are only meant to highlight the play on words. :-) It's just one of those ruff riffs, you know. The play is meant to highlight different understandings, not to suggest how the actual you reading here conceives of and delimits architecture. It is merely a thinking tool and rhetorical device. (Aside: "architect" may be a hat developers on the team all wear, or a role; we're setting that discussion aside here.)

“Software Architecture:  It IS what you think” -- you already have a working knowledge of what software architecture is.  Things like

  • Organizing structure of the system – components and relationships
  • Blueprint – architecture specification, component contracts (API docs, protocols,...), etc.
  • Decisions:  “"All architecture is design but not all design is architecture.  Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.". – Grady Booch

acrossBut. Which decisions?

“Software Architecture:  It is NOT what you think”

The architect decides which decisions are architecturally significant and hence part of the architectural intent, but decisions would generally fall within the bailiwick of architecture for these kinds of reasons:

  • Scope – we architect across. We use the umbrella diagram to illustrate architecting across scopes; across the internal boundaries within the system (components, microservices, services, subsystems, etc. depending on the chunking paradigms for the system in question), architecting across the system, architecting across the system boundary and its relationship with other systems. Architecture decisions are those that need to be made from the system perspective, taking into account their impact on system outcomes and the interacting web of other design decisions. For example, if a decision from the perspective of one feature or microservice or (sub)system would make it really hard for another, that's an indicator of architectural significance.
  • Timing – ground under the feet. The architect can’t just say “YAGNI”; the architect has to apply technical and organizational wisdom and think through what needs to be put in place early to allow the team to move forward, or because it will incur high cost to change later. Uncertainty is highest on the first day, yet we need to get started, and then we need to make progress – the architect has to be able to live with ambiguity and paradox! And resolve ambiguity and uncertainty by deciding, where that is critical; and exploring, or deferring. Deferring what we can, for then we know more. It is also not all "feed forward" -- we need to iterate, taking what we learn as we design (including the design we do in the process of coding) into account and potentially reworking at "higher" (that is, more broadly scoped) levels. As fits the extraordinary moment. For each unfolding moment. Over time. Not just early. Not just later. As the system evolves -- so throughout its lifespan. Judgment calls about what is architecturally significant, and when to tackle it.
  • Strategically significant, not just structurally significant – make or break decisions. Many characterizations of architecture focus exclusively on structurally significant decisions -- the emphasis on cost of change is cost of change to the system itself (so a code focus). Of course, addressing the structurally significant technical challenges of the system design is fundamental! But we also try to wedge open the space of architectural concern, because the system impacts value creation. The architect shifts her center of gravity, so to speak, from a technical/programming emphasis, to technical decisions in service of value creation and differentiation, or business intent and strategy – figuring out what the strategy means, and needs, and expressing this shaping intent in technical terms. Identifying and addressing structural challenges, and collaborating on shaping solutions that take the various forces, demands on, and desires for the system into account. This means outlining (technical) strategies sometimes, and designing mechanisms, at others. Again, judgment calls.
  • Design is fractal -- “turtles all the way down.” The system offers capabilities to its context, and these mean it, in turn, has internal responsibilities which get assigned to parts (subsystems, (micro)services, components, …) and collaborations among parts; those parts offer capabilities to their contexts, and have internal responsibilities… so “requirements” and contextual constraints and challenges at one level, get translated through design to parts with responsibilities at the next level.  This is not necessarily or strictly hierarchical; for example, a part may play a role in multiple mechanisms. But you get the idea. So what we tend to call “Requirements” for a system, is system design at a higher level (that is, broader scope). We need to architect across those boundaries, so the architect needs to be involved in crafting the system concept and architecturally significant capabilities. This informs the shaping of desired capabilities, with innovative ideas coming from what we can build with technology, along with ideas for addressing its limitations. And this provides contextual understanding, so the system (internals) architecting work can get started early (from the start) making the process more agile (responsive, adaptive, exploratory, iterative and incremental, etc.). It also provides a fulcrum for active feedback across the design boundaries (iterating not just on "solution" design at various scopes, but on strategy and system capability design). That way, learning is fed into more broadly scoped strategic design, as well as more narrowly scoped local design. (Re)Factoring of responsibilities, for example, becomes something that happens at many levels and over time. Again. Judgment factors. And factors and refactors.
  • Structure and dynamics – the structure needs to enable the dynamic behavior of the system and its intended properties (or qualities). Further, the system capabilites and properties, and our understanding of what is desired and what the tradeoffs are, emerge from the interactions within the system and between the system and its contexts of operation, use, and development; they take shape and evolve. (I recommend reading Decisions, Concerns ...(re-)Defining Software Architecture -- the section of Designing The Defining Structure makes points pertinent to this bullet.) The structure is a composition of mechanisms designed to deliver capabilities and properties of the system -- that is, the structure should not/cannot be designed without deep consideration of dynamic behavior, and resultant forces, that the structure must sustain and enable. And these mechanisms (and underlying structures) intermesh and interact.

“Software Architecture:  It is not what YOU think”

  • Not what you think alone – thinking “out loud” in small groups, with an emphasis on collaboration and participation, bringing more minds to bear; this is important when the system is complex, requires different expertise, etc. It is important to draw out, to sketch and model literally, but also to get ideas into a shared thoughtspace by talking, writing, modeling (in various media), exploring, understanding, resolving, elaborating, improving, sharing, .... collaborating, partnering, peer-ing!
  • The broader team (of teams) also needs to buy in to and understand decisions and be able to move forward. At some points and contexts, the architect may have to be that benevolent dictator with “a baseball bat” (more realistically, feather), but generally it is more about shaping, guiding, coaching, peer problem-solving. Regardless, software architecture is the outcome – if the design intent isn’t communicated and understood and feasible, etc., it won’t be what is built; the actual built architecture will diverge from the intention. Architecture is not a one person island thing, unless the project is a one-person thing. We need to strike a dynamic balance between participation and keeping things moving -- too many involved in thinking something through, and that snarls up just as surely as not including others.
  • Minimalist -- focus on essential architecturally significant decisions and defer the rest (in time and to others)

“Software Architecture:  It is not what you THINK”

  • It's also not just about thinking (important as that is), but about building -- paper prototypes or sketch mockups, code prototypes, pretendotypes, role play, slices of the system, the system! But using the cheapest medium to explore critical design routes, alteratives (I wrote lateratives and that is a nice malamanteau from, and evoking, lateral alternatives!), options.

The most pernicious couplings are to assumptions -- including those we don't even know we're making.



Accidental Iteration

These lines are in Sara's No Buts song:

You used to take my breath away
Now all your take are years

The first time I heard her sing it, I thought I heard:

You used to take my breath away
And what you take is yours

I like both versions. The thinking that happens in the spaces between, is important too. Even when it is an accident of mishearing or misunderstanding, innovation can come of the new connections.

So. I'm making my way into Cognition in the Wild with high expectations. :-)


Fall in Full Joy

By Dana

Dana took the above photo while we were out in the country today.


Positive Feedback

"Remember that a good friend is a new world.” -- Oscar Wilde

I love that. Friends open us to new experiences. And friends give us that feeling of resonance, of not being alone. So I'm right pleased I created one!


No-one liked the insight there? Serendipity is a mischief, like a sprite, but born of Emergence. And she is handmaiden to Epiphany.

Sheesh. What is wrong with people? ;-)

As feedback goes, I loved this essay:

In it, Kevlin noted:

"The absence of any positive feedback, by implication, suggests that there is nothing the person is doing right."


... No Buts.


Empathy, Vulnerability, ...

The courage to be vulnerable? I think vulnerability is simply conjoint with living all out, striving, loving, experiencing, learning, ...

I learned some hard lessons at the hand of life... My empathy may now be so pliable ...as to be useless...



Turning the lights off

Again. ;-) So, so, so much to do.



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
- September
- 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 © 2014 by Ruth Malan
Page Created:October 1, 2014
Last Modified: August 7, 2016