A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

August 2016

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

This is a journal -- where I write traces or musing on topics I relate to architects architecting architecture. I have been writing this Trace for more than 10 years -- if you're just discovering my work, it's not because I am new to this!

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?


About that Clue Bucket

In case you're just "tuning in" to this Trace and my work -- do take a look at my Architect's Clue Bucket slides:

Several people remarked on the quotes (used in the slides), and they are certainly wonderful! But it is worth remembering that the quotes are parts -- to be sure, they have considerable leverage, carrying a high payload of insight in a few words. Still, I hope -- and, frankly, believe (I worked hard to make it so) -- that the Clue Bucket slideset is more than the sum of its parts.

I heard Grady Booch outline the fundamentals of architecture (slide 16) in a (video of a) talk he did at Yahoo! years ago. I thought these "fundamentals that remain fundamental" (Booch) were worth highlighting, so I gave them a mnemonic (SCARS) and I expanded on each, to illustrate and inform them. The section on SCARS (slide 16-45), we might see as a module. Strong on its own. Worth pulling out any time you want to talk about architecture! Maybe that is why 109 architects have downloaded that slideset.

The opening "what I think about" in sketch form, is a playful introduction to what architecture is and architects do. That is, instead of talking about me in my introduction, I talked about us, about architects! About what architects do, and contribute. There is so much insight in each phrase -- yes, I say so myself (sorry), but only as a reminder to notice (unconscious bias takes its toll many ways). Structural integrity is job one

Consider, for example, "has structural oversight" (slide 4). [The image is intended to conjure visualization -- not just of structure, but how it works.] Architecture is very much about structural integrity, and integrity, while it can be destroyed by weak parts, requires attention at the system level, at the level of scope that includes interactions among parts. Integrity is about consistency and standing up to forces, and system performance under dynamic tension -- it's about resilience. Anyway, I could easily devote a month of traces to structural integrity. I did devote a month to the importance of someone being charged with paying attention to integrity at the scope of the system, not just the parts (features, [micro]services, components, ..., whatever the chunking) -- so if you missed my traces on the architect from February, you might find it valuable to stop by those traces. But it boils down to: if there is no oversight, architectural integrity will be an oversight.

And if that wasn't enough, slide 7 is art with a capital A. That's a mischievous wink, so you will go look. Okay, if my mischief comes across as braggy, rather than playful, skip ahead to slide 65 for art. That's a sketch by Amanda Muledy.

Oh, I know the introduction isn't perfect! I was being playful, and a few slides serve, at best, as stimulant or provocation (in good ways, hopefully) to thought, conversation, understanding. I just wanted to set the scene, set context and scope for my talk on clues for architects architecting architecture! Clues in a space where it is as much about finding clues as we go (the last section of the talk), as it is about having a bucket preloaded with them (the first section).

Anyway, that introduction is a first iteration across the space of concerns that the talk covers. The next iteration does so in terms of clues -- heuristics, principles, tips. But these clues are organized, structured, related to illuminate the design concerns of architecture. That is, they shed light on what architecture is, as well as how to do it (better).

The next module offers maps of the landscape of concerns that we address when designing systems. These maps serve variously. They help to direct attention -- what should we be thinking about? As we study in the large, as a field, but also instrumenting and learning about our system, and its fit to the purpose of its containing systems. What are we missing -- where are we neglecting to pay attention? Do we need to pay attention to it now, or is later good enough? Having maps also helps us to let go of working linearly, knowing that we can work over the space iteratively, apparently messily, but undergirded with a structure -- a solid sense of the design space -- that guides us, and gives us a way to cross-check that we are covering what we need to. Learning and advancing our design with sufficient sense and sensibility, even as we build out the system, and our understanding of what it must be and become, incrementally.

The "mapping the clue landscape" module (slide 59 - 92) is an enormous contribution to our field, and it is one that needs to be credited to Dana Bredemeyer not just to me. Of course, we also owe much to all the architects we've worked with over the several decades we've been doing this. Along with our peers doing research and writing, consulting and teaching as a vehicle for advancing the state of this field's understanding and practice. Shocked, shocked I tell you!

I realize you're busy, but take for example the code smells cartoon on slide 6 -- the two conceptual architecture diagram figures that are "shocked, shocked I tell you" at the entanglement and code smells? They're not (yet) embedded in the messy reality of legacy systems. They're idealizations of a simple system. See? And (also on slide 6) the "architect must address the kludge" -- see the face in the system? Recall Gall -- "Systems develop goals the minute they come into being" [slide 51]. ;)

When someone draws out some words that struck them, and/or says something positive, you see it -- maybe you see it more critically. Maybe you just take a more considered look, expecting more from it, and so getting more from it. I hate to have to be the one to say things like "great structure and content -- it just keeps on giving!" But when you put a career's worth of insight into something that is still playful and can be encountered at many levels, it's nice if a few people notice, and say something encouragingly positive, so a few more people can get value from it too. [I know -- the few people who regularly support me, are generous with time and encouragement! And I appreciate that! My work is... vulnerable... That is, it needs to be considered with the same level of consideration as I pour into it. It needs, and yields much to, a thoughtful encounter.]

And if you like the Clue Bucket slides, you might also like the Design Visualization: Smoke and Mirrors slides and notes. Remember to Like these on Slideshare, and share them at work and Twitter or Linkedin. Your peers at work will be most obliged to you for finding such a useful resource, and I will be most grateful for a little extra positive word about my work. We all need to tend the attention commons, and make sure the good stuff gets some attention.

Paying Good Work Forward

So. I've just talked about Clue Bucket slideset in (distastefully?) glowy terms. My bad? The thing is, we need to talk about my work in positive enough terms that it gets the attention of a few people. If no-one will say positive things about my work, unconscious bias has sway. I am very grateful to the people who have done so. But, it's always the same few. Every now and then, someone new needs to be generous and courageous enough to go out on the limb of their own judgment, and mention something useful I have done in terms that break the low expectation barrier. Own judgment? Well, when no-one else declares a work to be good, important, useful, then you have only yourself, your judgment, your experience and insight, to rely on. And that's a lot! So if you think it is good, say so! Thank you!

Oh, I know. You think that since I've already mentioned the Clue Bucket a few times, and it's a couple of months old already, its sell-by date is past? But no! It is never too late to notice something good, and express the good that you see in it -- that good you see, how you phrase it, is a new thing! It's a new insight -- it's what new reflection comes to light when your experience encounters my expression.

Okay. In truth, I'd feel really uncomfortable if, now that I've talked up my slideset like this, someone pointed to it in glowy terms. But next time you see something good in anyone's work, mention it, and even say what struck you, what insight it shook loose in you! Give it some positive exposure.

Very few people mention my Trace or other work, to others. Oh sure, prominent people in our field will say nice things about my Trace (this journal) to me on DM. Like this:

"You tend to examine all sides of a question, with references. That's what C2 used to be for."

from a fellow author and architect. But typically they don't mention it to others, so it doesn't benefit from the word-of-mouth exposure a work needs to get some of, to find friends. I don't want a lot of attention, but I like to work with new clients too, and that means architects at other organizations need to find out about my work.

Now. I must get back to work, and writing about context -- for context ... for context...



Cyrille Martraire did a really nice job of both writing up the perspectives offered in the open space on Decentralized Architecture that he facilitated, and offering further insights, observations and pointers of his own, in:

To some extent, our field has shot itself in the foot, when it comes to architecture. We have emphasized emergent design and de-emphasized architectural design to the point that we don't have a shared base level understanding of what architecture is. I don't have a lot of problem with not having a consistent or uniform understanding. I think it is vital that there are lots of experiments, approaches, directions taken in our industry. We don't learn, innovate and we don't advance our field, if we all have the same views, and do everything the same way. But a shared view among those sharing an architectural space is useful.

mapNow, one point of immediate ambiguity derives from the way the word architecture is used generally to mean both the discipline or field of architecture and [system] architecture. So, one place I (and Dana Bredemeyer) like to start, is by offering a broad conceptual outline of the space:

  • architects (who)
  • architecting (how)
  • architecture (what)

in context:

  • motivational (why)
  • organizational (where)
  • evolutionary (when)

That is, we use the 6 primary interrogatives to broadly frame the space of concerns covered by the architecture discipline. In particular, this means [taking the positions polled and reported by Cyrille under "Architecture Definition Ambiguity"] that we can separate considerations that fall under what:

  • “The norms & blueprints: REST API, Service-Orientation.…”
  • “The Main Decisions, especially the structuring decisions.”

from those that are more about, or have strong implications for, who:

  • Psychological comfort: “We expect the architect to comfort the team and reassure them on the quality of their decisions.”

And also from why:

  • “Ensuring consistency," “Avoiding doing the same thing twice," “Coordination between multiple applications.”
  • “Preventing accidental complexity.”
  • “Consistency, Technical Debt management.”

Now those are generic sorts of "why," and when we dig in, the why gets specific to the driving concerns and forces or challenges for the architecture in question. But the same is true for the architect. Generally, whoever makes any architecturally significant decision (whether they know it is structurally or strategically significant, or do so by accident) is contributing to the architecture. But, for systems of the kind of complexity that makes architecture important to be reasonably intentional about, we encourage being intentional about technical leadership and having an architect (and, if warranted by system complexity and scope/scale, a lead architect and team of architects who serve as lead architects for the (sub)systems). The style of the architect is going to factor, but we strongly encourage participatory design, among other good things -- including highly iterative design using the design palette/toolbox as best fits the decisions of the moment.

Separating the concerns has its usefulness, but they interact too -- an insight I tried to capture in the image (above) that I drew for my Trace topic map page.

But it boils down to: if there is no oversight, architectural integrity will be an oversight.



Architecture Workshops

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

What we do:

[7/7/16] Comments on student evaluations from a recent workshop (taught by Dana Bredemeyer), on the strengths of the architecture workshop:

  • Dana's practical experience and delivery skill
  • Very knowledgeable instructor with a lot of domain experience
  • The importance of the business and the technical side.
  • Applied background and related/applied discussions
  • Practical working exercises
  • Material; detailed concept explanation; use of different models in hands-on workshop
  • Confirmation of things I was doing; attention to things I was not

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
- April
- May
- June
- Current


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



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


More Archives






Architecture astronaut





Copyright © 2016 by Ruth Malan
Page Created: May 5, 2016
Last Modified: August 8, 2016