A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

April 2016

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

This is where I keep a trace of thoughts on wanderings in the landscape of software and systems architecture and those that abut and have bearing on our field. I have been doing this for 10 years!

To get an idea of what this Trace is like, here are some traces from February:

Architects: What are they good for? What makes a good architect?

To give further sense of the scope under the lens, here's a scattering of other traces:

Well, there are words here. And if you don't like to see words dance, move right along.


Upcoming Open Enrollment Architecture Workshops

In an email this morning:

"I’m told by the architects here, that attending Bredemeyer training is a must!"


More about what we do:




There are a lot of things our field thinks are "obvious," yet we're still learning how to really grapple with the fundamentals. Take something as simple as "what is architecture?" We swerved to miss the BDUF pothole, and shot an axle* in the NDUF pothole? We're so focused on being Agile, we learn at microscales, and set the process up to focus on small increments and flow with its throughput metaphors and its own set of pressures. And... We become mired in "technical debt" ... or entropy... or tar-baby entanglements... that increasingly stymie attempts to respond to emerging understandings of what users and "the business" needs from our system, in the context of other changing systems and unfolding opportunity. We want to be able to "pivot" responsively, even once we've amassed code load, and the modularization approach du jour is seized upon to get us there. OO, CORBA/COM, SOA, microservices... We've learned through this evolution, but new challenges arise, and the fundamentals remain, well, challenging and fundamental. We're experimenting with grain or chunk size for our primary focus of modularization, as well as the interaction mechanism that allows us to compose these chunks. Hopefully into systems. But system design -- at all for complex systems, but especially where the system is inherently evolving under adaptation pressure given evolving contexts of use and operation -- remains hard.

Early characterizations of software architecture (and systems architecture for that matter), focused on the organizing structure of the system. So we have definitions that spotlight architectural elements and relationships among them, along with system properties. Elements, or components, are (still) the focus, for example, of Simon Brown's (context, containers, components) approach to architecture, and others. It is also where we spend a lot of our attention. As the excitement around microservices signals, chunking and composing is still a matter for hitching our bandwagon to the pony of hope that we have at last reached an approach and undergirding technologies that makes our software highly ... swap-in-and-out-able. Code is so malleable in the small, at the local level of lines and methods and classes or functions .... Yet becomes perversely less malleable over time, as code masses. And masses. We want a chunking mechanism that retains isolation of manageable units, yet coherence in composition -- not just static but dynamic composition, scaling, evolving, commissioning and decommissioning and more.

In other words, the problem of "organizing structure" -- of elements and relationships, of interactions among elements to yield system capabilities and properties, doesn't just automagically go away with the "right" technology stack and supporting deployment and operations infrastructure. When these things line up better, are more consonant with our system (de)composition, we have leverage, purchase. But decomposition and composition to create coherent systems is still important, and non-trivial. To say the least.

Obvious? Well, yes. And the blindingly obvious blinds. Most popular characterizations of software architecture -- including those of Grady Booch and Martin Fowler -- focus on decisions. Sure. And the organizing structure embodies decisions, so bases covered, right? Well. What we're paying attention to, shapes what we perceive and pay attention to. If we say "architecture is decisions" (architecturally significant ones, obviously -- wink), then we whip out an architecture decision template to document them -- put it on github. Walla. Done and dusted.

Not so fast.

Oh pfft, don't get me wrong! I'm not saying that it's not important to document architecturally significant decisions and it's a nice template, though it misses, for example, alternatives we considered but ruled out. More on that later. I just mean that a decision focus is a hammer looking for its own kind of nails, and moves attention away from the organizing structure -- that remains a crucial and central concern of architecting.

Why should we consider "the organizing structure" of the system, at all, and why architecturally? Why think about decomposition and composition, about system "chunks" which we then have to compose and orchestrate? Isn't it good enough to let structure emerge from (TDDed) classes (and micro-refactorings thereof) or functions and relationships among them?

Want to read some of my talk? I'm extranormously busy, so it can only unfold in bits here and there, but shall I get started? Yeah? Oh gosh, you're so nice! :) Here you go:

Dana Bredemeyer said "Architects have to have self-repairing egos" and I snatched it up and wrote it down because it's so true! We work across the system <Ruth makes an arc with her arms>. It's a defining characteristic of architectural decisions that they (are the decisions that) need to be made from a system -- not local (to a part) -- perspective. And they're about achieving something strategically or structurally significant, make or break, matters of structural integrity of the system, sustainability, resilience, ... So not only do they impact different people -- stakeholders (the ones with stakes, to quote Tom Graves) -- but they are things people care about, and have strong -- but varying -- opinions about. Are seen from different vantage points where there are different pressure points, by different teams and their people, responsible for different pieces of the system. We achitect across -- across the system. And across the turfs and charters of teams, and individuals, and functions. Well. All this means that people will see things differently. Care about them differently. And as architects we need to make decisions to meet system goals. Decisions that will sometimes look suboptimal from the perspective of local goals. Make things perhaps harder or just not be what someone with a local charter would prefer (but where their preferences impact others/the system substantively more, making it of archtiectural import). So, over time, various darts are going to be hurled the architect's way -- hence the need for self-repairing egos. Sure, we listen and empathize, try to build understanding, negotiate and coach teams in surfacing system issues and addressing them together, involve people so by participation they understand the bigger picture and the tradeoffs that have to be made. But there'll still be darts. People, you know? Ambitions. Agendas. Real heartfelt concern we're not doing things the "best way." Lots of reasons the darts come out. I have found myself saying "You have a point. You can take it out of my back now." So. Architects will take some scars for the system.

And surprise! SCARS is the mnemonic I saw in Grady Booch's "fundamentals of software architecture":

  • Separation of Concerns
  • crsip and resilient Abstractions
  • balanced distribution of Responsibilities
  • Simplify

We'll consider each of these in turn.

More? What's that? I can't hear you... ;)


Psst -- this fits in well with one of my slides latish in the talk:

"The moment we open our eyes, we experiences a vast, richly detailed visual world extending well into the periphery [1, 2]. However, numerous experimental results indicate that the bandwidth of human perception is severely limited. Findings from change blindness and inattentional blindness demonstrate that much of the available visual information goes unnoticed [3]. Direct estimates of the capacity of visual attention (see Glossary) and working memory reveal that surprisingly few items can be processed and maintained at once [4, 5]. These results raise a natural question: why do we think we see so much when the scientific evidence suggests we see so little?"


"The ability to extract an almost immediate sense of the visual world provides ecological benefits, such as guiding further action, especially saccades. Saccades are important to this discussion because one reason why observers may overestimate their perceptual experience is that saccades are so effortless that observers often do not even realize that they are making them. This gives people the false impression that they perceive more than they actually do in a given instant because they are not aware of the serial manner in which they accrue information (i.e., one saccade after another). Furthermore, observers do not move their eyes randomly across a scene; they systematically go to the parts of the scene that are most informative for the task at hand. This ability to select saccade targets intelligently is possible because observers are able to take advantage of the knowledge they have obtained about the scene from its global image statistics"

-- Michael A. Cohen, Daniel C. Dennett, Nancy Kanwisher, Perception: Rich or Sparse?, The Limits of Visual Cognition, via Paul Harland

And this is loosely connected to the analogies slide:

"Thom Gunn has written powerfully of the “occasions” of poetry. Science has its occasions no less than art: sometimes a dream-metaphor, like Kekulé’s snakes; sometimes an analogy, like Newton’s apple; sometimes a literal event, the thing-in-itself, which suddenly explodes into unimagined significance, like Archimedes’s “Eureka!” in his bath. Every such occasion is a eureka or epiphany." Oliver Sacks, in recommending The Sense of Movement by Thom Gunn (1957)

Aside: When I read this paragraph (Oliver Sacks on Madame Curie by Evie Curie), I burst into tears:

"In 1998 I spoke at a meeting for the centennial of the discovery of polonium and radium. I said that I had been given this book when I was ten, and that it was my favorite biography. As I was talking I became conscious of a very old lady in the audience, with high Slavic cheekbones and a smile going from one ear to the other. I thought, “It can’t be!” But it was — it was Eve Curie, and she signed her book for me sixty years after it was published, fifty-five years after I got it."

A woman who influenced a man to science! And then there she was! And she signed his book. How lovely is that?!! If you don't tear up at that paragraph, don't tell me! I don't want to know!! :)


* well, sure, you're likely to take wheel or suspension damage hitting a pothole, but axle was a more vivid image right there (connecting, perhaps with the "don't get your axle too wrapped around" this image? ;-). Go with the feel of it, and you get more truth than nitpicking at the fact and probability level. :)


Slides: Design Visualization

Well, while you wait, you might want to see the slides from the talk I did in London? All the slides. And slides with notes for the first sections. Remember that if you like them, you need to Like them. That's the social contract, right? It's called reciprocity. You like. You social signal to others that it is worthwhile. Thank you. You're so wonderful! I know it's a pain to log in just to Like. But sheesh, people who Download and don't Like? What's that about? ;) Yes, yes. Even I need to develop some level of reputation. I need to fill workshops -- I earn my keep by delivering value companies pay for. Easy to overlook, I know.


Remind Me -- Never Again!

Yippy woo! I just got this in email:

"I want to say thank you for your presentation at the conference. It was one of my favorites."

It's an undeserved kindness, but having someone say that makes all the difference!

I also appreciated this tweet after the talk from another kind person:

"Thanks for the thought provoking presentation today!"

I'm just not good at the conference talk thing, but it helps my spirit heal to have someone offer the salving grace of a positive reflection! I won't even look at the evals. I know there'll be good and bad, but the bad will just crush my tender spirit and what'd be the point? I'm not going to do it again.

Workshops are so incredibly different. I generally use flipcharts (not slides) because workshops are an unfolding collaborative learning experience. I have so much knowledge to share, it is at the tips of my fingers and markers are a great way to help get it out of me. And other architects participating also have so much insight and experiences to contribute to our shared learning too -- even their questions contribute to opening up avenues of learning, but the working sessions and mentoring through those sessions are where a lot of the magic happens.

Conferences have their place as a kind of buffet of access to emerging and interesting work. But lectures are "the educational equivalent of 19th-century bloodletting," so workshops ftw! Whoo!

Also, why I can't talk from behind a podium:

‘I can hardly think at all when I am still,’ Rousseau writes. ‘My body must move if my mind is to do the same.’




I'm going to take a twitter break (with the possible exception of some links here and there) for a while. Hold me to it!!! :)


I also write at:

- Trace In the Sand Blog

- Bredemeyer Resources for  Architects


Architects Architecting Architecture'

- Software Architecture Workshop, Boston, MA, June 27-30, 2016

- Enterprise Architexture Workshop, Chicago/Schaumburg, IL, July 18-21, 2016


Journal Archives

- Journal Map

- storylines tubemap by Peter Bakker



- January
- February


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



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


More Archives






My alter-ego:


Architecture astronaut





Copyright © 2015 by Ruth Malan
Page Created:April 15, 2016
Last Modified: April 22, 2016