A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

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



Enterprise Architect -- Reprise?

Reprise? Well, this sounds like another swing around our block, doesn't it? But, if it doesn't sound familiar to you, it is high time you read The Art of Change: Fractal and Emergent. :-) Oh, Urquhart's post does take its own unique cut through the terrain and is well worth reading. But the ideas have been in play for a while, so there is other work worth tuning in on.part of something larger

As ecosystems and ecology go, here are some traces:

More on the evolving identity of enterprise architects:

Of course, this trace is a tour de force:

As is this:

And there is this (via Sally Bean):

Fields, or disciplines, like people, need to keep learning, evolving, adapting.


8/4/14: Move over enterprise architects, Watson is here:

A Room Where Executives Go to Get Help from IBM’s Watson Researchers at IBM are testing a version of Watson designed to listen and contribute to business meetings. By Tom Simonite on August 4, 2014

8/8/14: Tour de force? Tongue in cheek. Sheesh! :-)




Qualities Shape

"But let's drill into the nub of the problem. The reason that so many tools have become unwieldy is that they chase after certain values that add complexity but not usefulness to SMB-sized projects. For example, in the conversation I linked to last time, XML co-developer Tim Bray was struggling with Gradle, a build tool we covered recently in Dr. Dobb's. Bray was complaining of having to read through a 60-chapter document to get what he needed. Hans Dockter, the primary developer of Gradle, responded that the product was designed principally for scalability. This is an important detail. If you're considering Gradle, is scalability the problem you're trying to solve? If not, you might well be giving up simplicity for a capability that will not be used."

-- Getting Back to Coding, Andrew Binstock, July 29, 2014



Upcoming Workshops

Wow, a client just sent me the participant list for the Software Architecture Workshop I'll be doing with them in late September -- two months out, and not only is the workshop full, but I can begin shaping... Mwhahaha... I mean... That's a wonderful degree of anticipation!

Dana Bredemeyer will be teaching our 4-day Software Architecture Workshop at the Embedded Systems Institute in The Netherlands on December 16-19. Enroll soon to ensure a spot in the workshop -- remember, Dana is awesome. I'm biased, but he is fully booked by existing clients through the end of the year (and into next year), so people who have worked with him think so too.

I will be facilitating a 1 day workshop on Software Architecture at the Software Architect Conference in London on October 14. Come too -- Richard West will be there, and it's going to be awesome.

I've been asked about dates for an open enrollment workshop in the US. The only week I have available this year, is the week of December 8. So, what's the level of interest in a Software Architecture or a Role of the Architect Workshop that week? In Chicago?

This, from an earlier trace, might be useful:

The Software Architecture and Role of the Architect Workshops do overlap somewhat – where we do both workshops with the same people, the Role Workshop draws on an additional set of material, but in either case, architects will get the core concepts, guidance and key models for architectural thinking/designing/communicating, and so forth.  

That said, the design of the two workshops is different:
- The Software Architecture Workshop follows the Visual Architecting Process (informal)
- The Role of the Architect Workshop follows the Architect Competency Framework

However, a good part of architecting involves the “soft skills” of understanding what is strategically significant (hence what are the demands on the architecture and how are these shaped), and making and communicating decisions. These are technical decisions with business and organizational consequences, that need to be understood and embraced to be delivered on.  

Often, clients who have teams of architects of different “flavors” (software, embedded, mechanical and electronic systems, infrastructure, test, domain, portfolio, solution, enterprise, etc., etc.) will go with the Role Workshop rather than the Software Architecture Workshop, for obvious reasons.  But the essential skills of system thinking and modeling, strategic thinking (understanding what is shapingly important in the business space, so technical decisions support business intent), leadership, and so forth are going to come up in any of our architecture workshops. It is more a matter of what is primary and what is secondary.  In the Software Architecture Workshop, the focus is on creating a draft (set of views of the) software architecture, and discussions of leadership and so forth are secondary, but very, very important. (There is no point to making decisions that are ineffective either in their focus or in organizational follow-through.)




Meetings don't get much love...

meetings get bad press

My imp wants to interject with something along the lines of that being a responsibility plate we need to step up to...

"The quality of your architecture can't be better than the quality of your meetings" -- Dana Bredemeyer

Your inner Conway is doing gleeful somersaults at that? :-) We work with forces -- compression, tension, gravity -- to design and construct viable structures. Conway's Law is like that -- something we have to balance and counterbalance, to resolve, to create ambitious systems.

Meetings are a mechanism we can use effectively or ineffectively. Relationships are conduits for understanding and influence, and informal and formal meetings are convening places. We need to take more responsibility for the effectiveness not just of our relationships, but the time we put into developing them, and what flows through them.

Alignment and shared understanding of context and priorities and what we're going to do and such, takes getting heads together somehow, somewhen. Call them working sessions if you prefer, but sometimes minds need to sync up, move understandings across the chasms between our craniums, and create new understandings out of the interaction between minds and in the wonderful generative space that opens when minds ignite and spark off one another. It is a privilege to try to convey something, because in that very act, we discover what we think! Getting it out there, in words and images, is important to moving understanding -- our own, and others. The big things we tackle, can't (generally) be done by one person alone; we need some common ground, some shared understanding of context, its forces and constraints and opportunities... shaping perception of "reality" and how we are going to interact with and intervene within that reality to create something together.

I suppose, in a sense, politics is about power and influence, shaping resource flows. It can work through informal, or formal, by soft influence or hard, command and control, authoritarian influence.

8/13/14: Also:



Politics and systems

I like this point, and how it is put:

"You just look at the alternatives; analyze the merits vs. the problem at hand, and may the best option win. This works out well if you are the king (or work alone which makes you the king by default) -- otherwise there are other people and they won't necessarily agree with you."

Arnon Rotem-Gal-Oz, Architect Soft Skills, 10/26/08


(No) Strategy

There is a bit of an us vs them thing between strategy and execution, talk and action, theory and practice...

“In theory, theory and practice are the same. In practice, they are not.” ― Albert Einstein

"In theory there is no difference between theory and practice. In practice there is." -- Yogi Berra


"When you come to a fork in the road, take it" -- Yogi Berra

OH at Universal Studios (via Dana Bredemeyer): "Which way do we go to get somewhere else?"


Which recalls to mind:

"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat.
`I don't much care where--' said Alice.
`Then it doesn't matter which way you go,' said the Cat.
`--so long as I get somewhere,' Alice added as an explanation.
`Oh, you're sure to do that,' said the Cat, `if you only walk long enough.'

-- Lewis Carroll, Alice's Adventures in Wonderland

And this:

Alice looked round her in great surprise. 'Why, I do believe we've been under this tree the whole time! Everything's just as it was!'
'Of course it is,' said the Queen, 'what would you have it?'
'Well, in our country,' said Alice, still panting a little, 'you'd generally get to somewhere else — if you ran very fast for a long time, as we've been doing.'
'A slow sort of country!' said the Queen. 'Now, here, you see, it takes all the running you can do, to keep in the same place.
If you want to get somewhere else, you must run at least twice as fast as that!'

-- Lewis Carroll, Through the Looking Glass



So what is strategy? Here is Dana Bredemeyer's answer:

"Strategy is a process that asks, answers, and co-ordinates the interaction of these questions, and facilitates the evolution of this process over time:

  • Who we are (identity, values, ethics, capabilities)
  • What are our desired outcomes (mission, vision, objectives, goals and timeframes)
  • What is our context, or situation (the world, trends, forces, resources, evolution...)
  • What are the essential things we must do in order to realize our desired outcomes?"

Dana strongly advocates against pitting strategy and execution against one another in that "execution is more important than" kind of way. For those who insist on drawing out the distinction, Dana adds:

"If we divide the world up into strategy and execution, then I want to add a third component. I’ll call it achieving organizational coherence. This is the degree to which there is shared understanding and shared enthusiastic commitment to the desired outcomes and the strategy for achieving them. The ability of every organization, large or small, to do anything, is limited by what they can achieve organizational coherence around, regardless of how exquisite its planning or effective its execution."


Meaning, Pragmatically

I love the elegant way Herbert Simon evades the word police:

stearing what we mean

(from Herbert Simon's The Architecture of Complexity)


Eberhardt Rechtin was similarly skillful:

"The term 'architecture' is widely understood and used for what it is--a top-down description of the structure of the system." -- Eberhardt Rechtin, Systems Architecting: Creating and building complex systems, Prentice-Hall, 1991

Which gets us back to Alice:

Humpty Dumpty smiled contemptuously. 'Of course you don't — till I tell you. I meant "there's a nice knock-down argument for you!"'
'But "glory" doesn't mean "a nice knock-down argument",' Alice objected.
'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'
'The question is,' said Alice, 'whether you can make words mean so many different things.'
'The question is,' said Humpty Dumpty, 'which is to be master — that's all.'
Alice was too much puzzled to say anything; so after a minute Humpty Dumpty began again. 'They've a temper, some of them — particularly verbs: they're the proudest — adjectives you can do anything with, but not verbs — however, I can manage the whole lot of them! Impenetrability! That's what I say!'
'Would you tell me please,' said Alice, 'what that means?'
'Now you talk like a reasonable child,' said Humpty Dumpty, looking very much pleased. 'I meant by "impenetrability" that we've had enough of that subject, and it would be just as well if you'd mention what you mean to do next, as I suppose you don't mean to stop here all the rest of your life.'
'That's a great deal to make one word mean,' Alice said in a thoughtful tone.
'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'

-- Lewis Carroll, Through the Looking Glass

How very far we can go, when we let context and positive intent and positive expectation, inform our interpretation.

Goodwill, and a willingness to be playful.

[Confession... I used Random on xkcd to generate those links. ;-). A willingness to play... Testing. Testing. ;-) ]

[For meaning to be made, it helps a lot if we enter with a willingness to understand. We can become co-conspirators in the making, or we can be obstinate and obtuse... ;-) Of course,... life, having a sense of humor, ... immediately threw me a challenge...]hi freq imaging


Kraken, Live and Wriggling

Twitter dropped this kraken right into my lap:

Oh, to be clear -- the kraken is the beast of my own understanding, and I'm wrestling with multiple of its arms which are squirmy and I can't pin them down firmly and grasp it all...

I do like the notion of laying out the landscape of the feedback space...

(Hey, multivariate analysis is like water to my inner hounddogue ;-) Many fun. Such... Oh. )



Kraken Wrestling, Continued

The easiest dimension in Kent's feedback landscape for me to understand is frequency -- on what timescale do we want to consider feedback? If, for example, we want feedback every minute, we will only make at most a minute's worth of progress before we get some form of feedback. If getting that feedback involves some setup time, that enters our tradeoff landscape. How much we can get done per unit of time, enters consideration too -- if we are looking for feedback on work chunks that take on the order of a few minutes, the amount of work (or chunk size -- or scope?) we're getting feedback on is quite different than a day or week. That has implications for how much backtracking we might have to do, given the feedback. So frequency is interacting with setup time and the cost of being wrong -- failing the test, discovering where we went off course, and how much has to be reworked in the process of setting it to rights.

The scale Kent uses on the "scope" dimension threw me. The way I make sense of it (being labelled with scope) is -- the more code matter (or the broader the scope or amount of programming work we're getting feedback on -- lines of code, a class or other unit, a feature, a system, system in various use contexts) we have in hand, the further we can get down the axis Kent labelled "scope." [That's just my jaunty interpolation; I'm anticipating being set straight on how to read that scope scale and section! ;-)]

At those different points along the axis, the viable sources of feedback shift, as does what we can get feedback on. It is likely not viable to get market feedback in the form of dollar spend if all we have is merely a few lines of code (or a small increment of lines of code), but we can see if the parser snags or the compiler barfs.

So scope (simplified to chunk [which may be a chunk-of-chunks] size we're getting feedback on) and frequency -- lag time? -- interact with the source and nature of feedback.

As sources go, we can look to compute (giving feedback on the code: parser, compiler, ...; giving feedback on execution: logs and other mechanisms to sense and monitor operational data, etc.) and to our audience/stakeholders --

  • developers (state of the code);
  • operations (state of the system in operation -- runtime properties like scalability and availability, etc.);
  • users (state of the system in use -- capabilities or function and runtime properties users care about);
  • others --- customers (businesses of our users); others in the value network; our business (senior management, shareholders, etc.)

We can't get feedback on value from the compiler. We can't typically get feedback on scalability from the user, at least when the user is wearing their "user" hat. Etc. The user, usually, is not going to be able to give feedback on code qualities like understandability and modifiability. And while they could catch things we just did wrong, we want to catch errors in our logic/thinking before they are deployed to users.

So we need to ask ourselves: What is the nature of this decision I want feedback on? What is impacted? Who cares? What do they care about? How can I tell if I'm on track? When and how can we get feedback that illuminates whether and where we need to make course-corrections?

If we want earlier feedback, we need to ask what kind of feedback is viable, on what timescales, and how useful is it. Can we construct proxies, or indicators, so we can get earlier feedback, and can we create useful rollback points, so our building blocks can be swapped out and replaced more readily?

Unit tests test whether a code chunk meets the expectations/commitments we have for that chunk (built right), not whether those expectations are useful/valuable (right system). But our expectations are constructed as intermediate standins for a larger chunk of value that we can get different modalities of feedback on, from different feedback sources. And we want to get those other forms of feedback as early as possible, too, so that our cost of being wrong is kept manageable.

Which I suppose flips the consideration space. What can we be wrong about, and how quickly can we catch and correct mistakes, misperceptions and missed directions? And how does that interact with setup time/cost? And what scaffolding do we need, so we can rollback and correct?

And so forth and so forth... ;-)

Why am I interested? Have you read Getting Past ‘But’?? ;-)

Or seen this:

VAP -- test early and often

Yes, we bring testing (that is, seeking feedback) forward. The feedback landscape is quite germane.

Of course, it is messy...


Um. Messier still...


Well. Probably more messy than that, but you get the idea. Goodwill, a willingness to be playful, and a sense of humor.


Remind me to remind you about good, right and successful, and right system built right, and the feedback landscape, okay?


[The clarity dimension? You tell me. My sensors sniff red herring, but that only means there is something more there for Kent to teach me, if only in the form of me being nudged to discover what I think. Which is the best sort of learning, and gets us back to Kent's tweet. The phrasing of which threw me, because it is a trojan horse or head fake sort of thing. ;-) Let me remind you -- I know. ]

[The more narrowly scoped what we are evaluating is, the more finely we can target it, so the objectives or desired outcomes we are assessing against can be stated more concretely. And in that sense, we can resolve our assessment criteria so we get binary red/green fail/pass feedback. Widen the scope, and more comes into play. More interactions, more tradeoffs, more shift into qualitative judgment calls. Etc. ]

8/19/14: A while back (May) I focused on TDD as one of the tools in our design thinking toolkit. Here we focused on the feedback landscape, and locating TDD within that landscape. Back in May, I collected together links to several posts on TDD, especially related to "why TDD" and TDD and design. Here's another, with a different slant:



Face with a View

My impish sense of humor really wanted to add the image (snipped from this trace) below, to this exchange:

face with a view

Puts a little spin on that "face with a view" [now I have to add another set of brackets to self-(d)e(f)facing!!] in the context of self-promoting my Trace. ;-) Especially when I'm the only one who enjoys it? Ewwww. ;-)


[Ummm... I came of age with the incongruities of South Africa and Monty Python/Fawlty Towers playing in the background. Not 'scuzing nothing, just 'splainin. Dana asked what that dog picture (on the kraken post) was about... I showed him what my face does after I've gone diving into a pool chasing the stick of my own understanding... Yep, my jowls... I showed him literally what I meant figuratively. These things are not pretty. I grant.]


To Rules, or Not to Rules

Saw this (via Ivo Velitchkov):

to rules, or not to rules


and was reminded of Michael Feathers' keynote at Ruby Midwest last year, where he makes the case for "Deliberate Reflective Design" (a call to use judgment rather than uniform application of standards and principles).


They're Different Beasts!


Like... Who knew?

Context, and all that?

I do like Alistair's post -- much that is super-good/useful in it, like the "value center" notion and the importance of mood and trust.

Teams have been tackling the issues of complex systems and their implications for complexity in the organizational structures and relationships all this time, and there was a lot of stonewalling when it came to organizational complexity and system (of complex system) rooted complectification. ;-)

We have learned a lot from all over this industry. We have much more to learn. And it seems like we can learn a lot if we acknowledge that some frontiers have been pushed while others were paying attention elsewhere. Models got shoved under the rug in some places, but reshaped and repurposed in others. BDUF got fed into an iterables pipeline, or something, and is now a whole different flow-and-transformation dynamical structure. ;-)

We can treat each day in the software world as an entirely new day, full of fresh-born unprecedented insights. Or, we can understand that we have a lot worth building on. Okay, we also have to toss some stuff. I'm just saying that the 'tude may be what needs to go into the wash first?

We put Curiosity on Mars, people. Sometimes we do hella complex things. Sure. We fail. Sometimes it's whale of a fail. But still. We do big things, too. Like your car? Sure, it's glitchy, no doubt. But... Lots of software in those things. We notice the fails -- they bug us, even maybe endanger us -- but it can be easy to overlook how much we have come to depend on complex software woven through our lives.


Sharing Shoulders

I've been enjoying Kevlin Henney's slidesets -- in good part because Kevlin does a really nice job of drawing upon classics by the pioneering luminaries of our field. as well as more contemporary work, like blogs. It makes Kevlin's work stronger to explicitly do that "I'm standing on the shoulders and ashes of giants" (Booch) thing. Gene Hughson likewise does a lovely job in his blog of drawing on other perspectives and work.

8/17/14: Yesterday I watched:

It was neat to get the words Kevlin puts to those slides, and see/hear him in action -- engaging and insightful.

Because we position principles in the architecture space, I have had to wrestle with the term too; this is how I put it:

An Architecture Principle is a normative statement that orients (or loosely steers) and aligns decisions and actions so as to achieve strategic outcomes.

A design principle is one that helps us to attain sought design outcomes.


Sharing Economy

Blogs and microblogging like Twitter, videoblogging and Youtube, along with Instagram and more, brought radical disintermediation to publication and other media. But publishers also served to vet quality and get word out. They set a bar, so reputation and trust came along with the name in print. As we move ever more to disintermediated media, we take on the mantle of getting word out about work we want to encourage and support. If we see this as an attention sharing economy, will we do more to direct some of the attention we so readily give to the "1%-ers" to others who are deserving of sharing some of the attention capital?

This is the time of our lives -- let's make it great for each other. Notice, appreciate, celebrate, connect. Too late always comes too soon.

8/13/14: Mutualism... simulation of ecosystems, not social networks... but interesting:



Tonality, and Traces Past

This, from a trace in 2009:

I do tend to (over)use parentheticals, and challenge and stretch the laws of grammatical gravity. Reflecting on that habit, I realized I (try to) use all the powers of (otherwise flat) text to simulate or substitute for tonal variation. This reminded me how important tone is in conversations, and how, working ever more in distributed teams, we have to find ways to bring that kind of vibrancy into written correspondence. Styles differ, of course. One of the chief architects we work with, writes quite brief emails, but each one has a point of original humor so delicious I always read or forward the email to Dana. (For his part, Dana laughs with such infectious enjoyment, one wants to make him laugh!) I don't mean that tonality is simply a matter of gravitas, though it is that. And social dynamics are so important in collaborative work; team "flow" is not just workflow momentum but a matter of fun and openness to influence that generates creative energy. But the artful use of tone also attracts, and shapes and directs, attention. Not that I am artful on that score. But I am enthusiastic. That's not nothing. Right?

That struck me, because... yesterday Sara read the xkcd banner caveat out loud to the kitchen gathering:


and I thought my Trace should come with a banner warning: this Trace contains RECURSIVE HUMOR (WHICH MAY BE UNSUITABLE FOR SOFTWARE DEVELOPERS).

Tee hee. Uh oh. I see pitch forks. ;-) [Recursive and humor are all very well, but put them together? And point them at me? Not a good idea!!! Except that No-one reads here. Phew. :-)]

No comment facility on this Trace? Makes sense, considering...

Recursion? Oh look what my brain found in the tweet stream (thanks to Pablo)::

Okay. That's it. I'm outta here. ;-)






It's Microservices all the Way Down... I Mean, Everywhere You Look


I'm Cool




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

I've offered the following for discussion in workshops from time to time:

Conjecture: SRP applies at the level of abstraction of the abstraction. [Further conjecture: this is what cohesion means (in actionable terms).]

Knock-down argument: at larger grains, abstractions may play different roles, and hence have different responsibilities (or responsibility clusters)

What do I mean? Well, for example an engine "converts energy into useful mechanical motion." A carburetor "is a device that blends air and fuel for an internal combustion engine." Each has a single cohesive "responsibility" (or defining purpose?), but the responsibility of the engine is at a different level of abstraction from that of the carburetor. Sure, the "engine" abstraction has sub-responsibilities that align to produce its primary responsibility. The conjecture is that it is useful to design abstractions with the (guiding) principle: a single responsibility at the level of abstraction of the abstraction (or element or concept or part, etc.); alternately put, don't have a mix of responsibilities that cloud the defining purpose of the abstraction. messierThat is, separate abstractions along the lines of cohesion of concerns.

Of course, judgment factors. And factors and refactors. Which is to say, as we consider responsibilities and various alternative factorings, we may redefine the defining purpose (or generalized overarching, unifying responsibility) of the abstraction under consideration. And so it goes.

You know. Messy.

7/18/14: More? Oh all right:

<Er(r)... um... Ruff -- Why did you put a link to tautology on "means"?>

Well, you see. It's the point, isn't it? What? Playing with the circularity. The iterative nature of it. Judgment factors, as in judgment is "something that helps produce or influence a result." Using judgment, we factor and refactor. As in, we cluster responsibilities and see how that does against our sense of design integrity, desired/required qualities, etc. And then maybe we try another factoring. And. We factor in, we factor out -- we weigh concerns, determine what is irrelevant, what is "tantalizingly almost relevant" (Bucky Fuller), and what is central.

A useful principle guiding our design thinking as we factor responsibilities and craft abstractions, is to seek cohesion within our abstractions, which may be expressed as alignment of responsibilities around a defining purpose, or an overarching, unifyng responsibility. Which produces good things. Modularity being one. Yep. CRC baby. At the level of abstraction of the abstractions we're designing.

Design is not a set of equations, but we are making tradeoffs and judgment calls, resolving competing tensions. So we need to do that deliberate reflection thing. And apply heuristics and guidance drawn from past experience -- do that "standing on the shoulders and ashes" thing. [And ashes? That was Grady Booch's term (I don't know if it was his invention, or if he was standing on shoulders there himself), and I like it -- we build on what we learn from failures, not just successes. As well as those who have gone before, so ashes in that sense too.]

And yes. That's just SRP. And CRC. Nothing new here. But you see, there is. There is the Master Butcher. In a workshop recently, an architect protested that he did that stuff in the 90's. True. And not. There's hacking the system-beast and dulling the figurative knife with each metaphorical ox that's slaughtered, and there's finding the natural structure of the system. Therein lies mastery. A willingness to find the natural divides, and when it gets tricky, to slow down and go carefully.

Aside: Of course, the knock-down argument applies to the engine example -- for example, the engine provides heat to the heating system. Nonetheless, the focus of the design of the engine is on its primary purpose or overarching responsibility.

8/19/14: See also:


Object Synonymous

Object Synonymous

Actually.... the idea of 'modeling the world' was only an approximation anyway. We mix various analogies from the "real world" into our code concepts. Some come from the domain, some from elsewhere. Our mechanisms for system-serving capabilities, for example, often cut across business domains, and have names that bring information/ideas from other domains into ours -- think fork and bridge and port and so forth, ad infinitum. [System-serving capabilities? Like logging, persistence, prioritizing and resource allocation, and so on, and on. Of course, mechanisms are generally cohorts of components collaborating, and the analogy may have more notional leverage than structural.]

I've suggested, jokingly, that analogy-oriented programming should be a thing. :-) But there is something serious under the jesting, which is the tip to look for analogies not just in the business domain being served, but in biological, mechanical and social systems too. Not everyone dances with analogies quite as readily... So. Caveats apply.

But. History is old. What are the interesting forward-looking ideas we are being tantalized to rout out? Services know how to take care of their own business, so to speak.


The tl;dr version of this trace:



Merit plus Generosity!

Anyone who thinks this is a meritocracy is forgetting that merit in a glut of merit needs something more...

'Assaf Naor, an Israeli mathematician who has worked closely with Khot for almost a decade, nominated his colleague and friend for a $200,000 Microsoft fellowship in 2005, the National Science Foundation’s prestigious Alan T. Waterman Award in 2010, and this year’s Nevanlinna Prize. “I see in his work more than just a collection of really good papers: I see an agenda, an original point of view,” Naor said. “There are many talented people who can solve problems — few people can change the way we look at things.”'

-- What It Takes to Win the World’s Highest Computer Science Honor, Thomas Lin and Erica Klarreich, 08.14.14

Advocacy is also personal -- those who generously and insightfully point out and show others important ground breaking work are crucial too. If not for them, the work goes unnoticed and unappreciated.


"extraordinary act of intellectual generosity"

My Trace?

Alas, no. But. One day? ;-)

I know. I know. Lots of fails, but hey, that's how we learns, right? Posit, explore, test. Sounds posit-ively...





Ordered; arrives Monday -- yay!

Ordered yesterday. Arrives Monday. This one I need on paper -- I expect to scribble all over it, and I like to do that on paper. It's how my mind leaves the trace of its melding. ;-)


See You, See Me

Yes, that is meant to produce Say You, Say Me echoes. And, in turn, Echoes. :-)

I've been enjoying Peter Bakker's photo stream -- seeing what Peter notices and captures. There's the physical world, and there's what an interpretive artistic mind sees and expresses, shaping what is presented for us to see (into). It strikes me, too, when Dana and I both take photos, what he notices that I never even saw, until I'm looking through his photos. Likewise, when we've been in the same meeting and share notes afterwards. He'll be like "what, he said that?" and vice versa. Not only are we different, but paying attention to some things means not noticing others. So when we put our notes and noticing together, a rich picture forms.



Why you no retweet:

why you no retweet?


I mean... if that doesn't get retweeted, then there is no hope at all for me...

No wonder I don't get retweeted.... (a few exceptional exceptions excepted)...




It's Feathers Day Y'all!!

Feathers Day you'll

Need the backstory?

Here you go:

this is the way to do it!

So. That means he's made it to the over side of the hill, right? Oh, you know, the warranty on all the parts expires, but the value just keeps going up on vintage models like him.

We should roast and toast him, right? We all know his technical work, and appreciate the contribution he has made to our field.

And we have this sense that... he is... unique...

In a twitter-topping way!

(Sorry Nein)


Yes, really:

  • Truth is danger then fiction, 7/22/14
  • Email is the log viewer of your life, 7/22/14
  • That moment when everything you know about human nature is true, 7/18/14
  • When your mind changes, so does everything else, 7/17/14
  • Abstract until there's nothing left and then undo once, 7/1/14

And that's just a smattering of mfeathers from July. Your mileage may vary, but mfeathers has a way of busting up hard-packed assumption ground, so new insights can flourish... Or... he whips the dust covers off our mental furniture, confronting us with our preconceptions... Or something... :-)

"Just when you think you know something, you have to look at it in another way. Even though it may seem silly or wrong, you must try!" -- Dead Poets Society

Michael's aphorisms work, often, by unsettling, surprising, rejiggering, more than by darkness (there might be some; life, you know), but since aphorisms are topic du jour today, this (via Richard West via Ivo Velitchkov) struck me:

"It was in the salons that La Rochefoucauld developed the literary genre for which he has become known: that of the maxim or aphorism, a pithy statement that deftly captures a dark insight into the human soul, reminding us of a wise and often uncomfortable truth. In good hands, an aphorism should deliver its punch in less than three seconds (one might be competing with the arrival of an asparagus tart)."

The Great Philosophers 15: La Rochefoucauld

Well, life is full of shadow and light, so what Michael deftly plays into sight, may be dark. Or not. It's more about insight, but with distinctive playfulness.


When to Roast Toast 'im?

And. We'll have to find out when that secretive shadow-man Pablo has his roast-day, so we can say what an awesome blog he has been building. The latest is masterful! As one has come to expect. :-) I wrestle the kraken of my own (miss(ed))understanding. Paul's images are so much more...

Well, did you get a trace of that scent? Don't try this at home, kids.

As embodied cognition goes, this exposes a literal insight:

"An alternative explanation proposes that gesturing is functional. It helps us retrieve words from our mental lexicon. The speaker says “At the fair we went into a uh…” He falls silent and makes a circular motion with his hand. He then looks relieved and finishes the sentence with “Ferris wheel.” The idea here is that the motoric information that drives our gestures is somehow connected with our word representations in our mental lexicon."

-- Rolf Zwaan, Why do We Make Gestures (Even when No One Can See Them)?



On issues that seem to divide us -- whether it is #noestimates or one of the -isms -- it might help to remember that often people are merely trying to offer a perspective they perceive we lack or may have less access to. We are exposed to different realms of experience, different social forces (much the same, much different). But then, we think they are lacking some perspective we hold, so we offer ours. And they think we didn't get it, so they add emphasis and argument to theirs, and we to ours. That can push us poles apart, unless we recognize it is just the dance of dialectic even though emotions and subliminally cued responses can pull it off kilter as we strive to achieve balance.

Twitter brings so much of the dark side of humanity to our attention, and it's important -- if it weren't for words and images bringing new awareness, how would we reorient and make change possible within ourselves, our organizations, and cultures? But it is also wonderful to lean into great work, and feel the good that people do. See the kindnesses and warmth.





I pushed self-reference to the limits today. I'm so happy that @RiczWest got the (full) recursive joke! Humor pipelining in Twitter? ;-)

When people seldom tweet or retweet pointers to one's work, it really erodes one's confidence, you know? It leaves me feeling that I #fail at this social thing...

But -- gratitude! The exceptions prove exceptional, and I am most fortunate. A few people are very nice to me. To ME! You understand. To me! How unlikely. And yet, necessary.




Repost as a Service


It comes from this Shaping trace, but all March 2013 is worth a drive-by -- it's ...well... awesome, if you ask me. Oh. Right. You didn't. Well, pfft, I never let that stop me.


Robin Williams Tribute Series

Continuing our tribute series, we watched Patch Adams tonight, spilling tears for all that has happened this past week. Indifference... my, that strikes such a chord...

PATCH: If we're going to fight a disease, let's fight one of the most terrible diseases of all, indifference.

as does:

MENDELSON: You are focussing on the problem. If you focus on the problem, you can’t see the solution. Never focus on the problem. Look at me! How many do you see. No, look beyond the fingers. How many do you see? By gazing through at Arthur beyond the fingers hero sees all fingers double.

PATCH: Eight.

MENDELSON: Eight, eight. Yes, yes. Eight’s a good answer. Yes. See what no one else sees. See what everyone else chooses not to see out of fear conformity or laziness. See the whole world anew each day.


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
- 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: August 19, 2014