A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

May 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 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?



[4/18/16] 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 micro scales (good!), and set the process up to focus on small increments and flow with its throughput metaphors and its own set of pressures (whoops!). 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 (useful and well described, with an actionable explanation/motivation for each field), 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! :)

[5/5/16] Here's the slides:

[4/18/16] And here's a start at a write-up:

Dana Bredemeyer said "Architects have to have self-repairing egos" [slide 15] 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 architect 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 architectural 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
  • crisp and resilient Abstractions
  • balanced distribution of Responsibilities
  • Simplicity

[5/5/16] I see that at SATURN this week, Grady put it like this:

  • Crisp abstractions
  • Clear separation of concerns
  • Balanced distribution of responsibilities
  • Simplicity

which are formulated as attributes of good architecture, which is nice. Still, I retain resilient (as in crisp and resilient) from earlier Booch fundamentals, and you'll see why. I also prefer my ordering -- not only because it lends itself to a (playful) mnemonic; you'll see why.

I like to introduce a discussion of separation of concerns in the context of architecture with a story [slide 17]. Yes, if you've followed along here for that long, you know the one -- the Taoist story of the Master Butcher. It is used in many contexts, but I use it to talk quite literally about finding the natural structure of the system. Although, I am not saying your system is a cow! Obviously. :) I first heard this story from Dana Bredemeyer, and I liked his emphasis on this part of the story:

"However, whenever I come to a complicated place, I size up the difficulties, tell myself to watch out and be careful, keep my eyes on what I’m doing, work very slowly, and move the knife with the greatest subtlety, until — flop! the whole thing comes apart like a clod of earth crumbling to the ground."

Some time ago, I heard a surgeon on NPR talking about the privilege of holding the trust of patients to such an extent that he is able to open up their chests (to do a needed surgical procedure, obviously) and hold a living lung, see the robin's egg blue of the gallbladder, and so forth. This image may feel somewhat creepy to us, but imagine how creepy it would feel to a surgeon to look at the software inside our systems!! :) And would they be as impressed by the structures we've crafted? How distinct are they?

[5/6/16] Why do we care about a "clear separation of concerns"? Again, this is blindingly obvious, fundamental. Not worth restating. Yet "big ball of mud" is the dominant architectural paradigm, is it not? We have to work hard to not do that. So it's just as well to remind ourselves why we care. One of the primary reasons is tractability. We can't deal with everything all at once, and a separation of concerns helps make complex systems (embedded in still more complex systems) cognitively and organizationally tractable. We can't hold complex systems in working memory -- there's just too much to hold in mind, and we need a means of chunking, zooming (in and out) and panning. We may not have the expertise to even understand the whole system (with all of its related domain knowledge). And, given not just skill and expertise requirements, but competitive timeframes, teams need to be able to work effectively, bring more minds and hands to bear, to create and evolve the system. One approach is to decompose the space we attend to, by separating concerns. Looking to separate concerns along the lines of the natural structure.

And lo, when we look at architectural patterns like layers in the POSA (Patterns of Software Architecture) book, published in 1996, we see repeated themes that occur across systems:

  • the work is too big for one person, so we need to effectively engage teams of people ("the system will be built by a team of programmers, and work has to be subdivided along clear boundaries--a requirement that is often overlooked at the architectural design stage")
  • parts of the system should be exchangeable; components should be able to be replaced (possibly even at run-time) with alternate implementations without affecting the rest of the system
  • code changes should not ripple through the system; they should be confined to a component and not affect others

Along with the need to balance several forces:

  • need to decompose into components (teams, reuse/plug-and-play/component exchange, change isolation)
  • how we group responsibilities impacts understandability, modifiability, coherence and coupling
  • crossing component boundaries may impede performance

... in progress, yo.

When I get to dependencies, abstractions and tradeoffs, I'll refer to this:

"Design patterns encode the advice that an expert programmer would give to a novice. Powerful languages have them too." -- Keith Braithwaite

This discussion thread on abstractions and ecosystems ("rising tide" you may say), is also related.

6/4/16 Okay, so the first paragraph on this trace, and others besides, fall into "colorful rhetoric" exaggerations... We caricature for effect, and that serves to entertain and grab some scarce attention cycles -- maybe. And we do it, with the uinderstanding the we're all grownups and know that in the gamut of projects and systems, some run to the extremes. But mostly smart people are keeping them off the disaster ropes, so "big ball of mud" architectures are not all altogether snot-holes of rot, See, I'm doing it again. ;) Our systems, even pretty soon and then more, have their pockets of gnarliness, and lesser and greater degrees of slide into entanglements... So the point, is still the point. (And now we know whose back it's in?) Crisp boundaries are hard to maintain, especially when they are already hard to put in place. Software is conceptual stuff that requires us to be both intensely analytically minded and... well... imaginative enough to bring code elements into named existence and concert with other elements to do stuff. That stuff, like phyisical stuff, attracts stuff. It's hard to keep it apart. We can try to, and functional programming is forging new mechanisms...


Thank You for Giving the Clue Bucket Slides Advocacy on Twitter, Slideshare and LinkedIn!

5/5/16: 1 Like (on Slideshare; a few more on Twitter). The "first follower" video comes to mind... How awkward if no-one follows! But if no-one follows the first follower, then it's awkward for him and all the more awkward for me!! So it takes a lot of courage and self-sense to be a first follower. Okay, Like-ing on Slideshare isn't really following, but it is still going out on a limb, showing support. Kudos to Amitai for kindness and courage, and risking his cred. :)

5/6/16: Now up to 3 Likes (on Slideshare)! Thanks Amitai Schlair, Marc Burgauer and JP De Vooght!!

Also huge thanks for mentioning the Architect's Clue Bucket slidedeck on Twitter:

"I recommend being and/or becoming the kind of person who likes this sort of thing." -- Amitai Schlair

"nice pack!" -- Adelbert Groebbens

"The Architect's Clue Bucket #softwarearchitecture #softwaredesign #solarch http://www.slideshare.net/RufM/the-architects-clue-bucket … via @ruthmalan #FF #getaclue" -- JP De Vooght

And thanks for retweets: Gene Hughson, Steve Merrick, Susan Almon and Valentin Mocanu

5/9/16: And thank you to Tom Graves -- who networked the slidedeck around on twitter, liked it in on Slideshare, and mentioned it positively on LinkedIn too. I hope you're following Tom! He shares his insights generously, making so much knowledge and wisdom freely available to us. But he does more, also generously cultivating this field by actively supporting, encouraging and sharing his platform for bringing attention to contributions that others make. I try to take that stance too. We make all the more serious contributions to pushing the frontiers of this field and the state of its practice, if we are not just about pushing our stuff, but rather sharing and even advocating for the various perspectives we each offer. As confident as I am in the value of what I bring to this field, I know that I have a bounded experience set but also a particular style. It is a good thing that this field is served by me, but also by others! ;)

On LinkedIn:

"Thanks to Tom for sharing this SlideShare presentation, it resonates well with me about what it means to be an architect." -- Winston Sucher

It is quite gratifying to see the response on Slideshare and LinkedIn. In less than a week, the Clue Bucket slidedeck has been downloaded almost as many times as the Design Visualization slidedeck in more than 6 months! It just goes to show what some positive words can do, to raise interest in a piece of work.

5/10/16: And. Thanks too to Eugene and Uwe:

"Vish is right. More great IT architect stuff from @ruthmalan ... check it out:" -- Eugene Barker

"really sad that i missed that presentation - would love not only to see the slides but also hear the voice track" -- Uwe Friedrichsen

TBH I'm so sure the voice track is terrible I haven't even looked at the video. I hope it just dies in a hole, quietly. It's complicated, so we'll just leave it at: I won't do any more formal conference talks. (Workshops are my zone, because it's about what I bring out in architects.) But it does mean that the support for the slides is an important ego salve. :)

HumbleBraggingIt5/11/16: Downloads on The Architect's Clue Bucket have taken off (relatively speaking). Nearly 5% of everyone who views the slideset, downloads it!! That, right there, is really rewarding! 11 Likes on Slideshare is a nice public showing of support. As is this, on Twitter:

"So much good stuff here: The Architect's Clue Bucket #softwarearchitecture #softwaredesign http://www.slideshare.net/RufM/the-architects-clue-bucket" -- @d-snyder

Also, 83 mentions on LinkedIn to 21 on Twitter... makes me question where I spend my "virtual watercooler" moments! ;) Just kidding. Very different support for social interactions across the two, but I do need to spend enough time on LinkedIn to even know what that's like!! I've always thought since I don't even have time for Twitter, I shouldn't let LinkedIn set habit hooks into me too. :)

The positive framing definitely helps -- thanks for the kind words!

It's wonderful to know that the slides resonate with so many architects! My delivery may not engage everyone, and those who don't like it react so harshly. In that context, the positive response, though private (Slideshare shows who Likes, but not how many or who Downloads), is encouraging.

So Twitter. Looks like you need to up your game when it comes to advocating the work of this WiT, anyway -- LinkedIn ahead at 83 to 21! As for Facebook -- I didn't know anyone did work related stuff on Facebook! Wow.

Gamify Mentions, ftw!

The surprise of this level of support.... and I am almost chuffed enough to write a book, goosh darn it!

But :( Downloads have stopped at 68. Sigh. ;-)

5/12/16: So, Slideshare has a bug on its LinkedIn Mentions counter... interesting (given the corporate family structure)... But! More kindness to tally! On Twitter:

"Super Slidedeck" -- Sally Bean

"So many good slides and references; The one about location, location, location made me laugh out loud." -- Sally Bean

"what a fantastic presentation. So many good quotes!" -- Luis Servin

And a comment on Slideshare:

"Bucket? More like a barrel of software architecture nuggets. Highly recommended." -- Sally Bean

And more retweets -- thanks Uli Deiters and Paul Harland and Marc Burgauer

Is this a bit.... icky? Posting praise and mentions and such? The story we tell ourselves impacts our view of what's going on, and I do hope you're telling yourself a wonderful story in which I come out looking good, and that you haven't tarred me with the jerk brush, or... worse! We have constructed a world in which we tell people to accept -- even seek -- criticism, that praise is manipulation, etc. Well, I rebel! I think we need a context that gives us positive feedback, and I don't get much. So when I get the overt, harsh criticism that does so surely come my way, it is very useful to me to be able to go back over the positive reflection of good I do. It is also useful for others to see that positive, and not just the negative. We live in social worlds, and how others regard us impacts how people receive our voice and our work. You can see as the story unfolded above, that some enthusiasm for the slideset led to a flurry of interest -- nothing so big as to do my ego any lasting damage, but enough to salve the hurt that harsh criticism inflicts. :) It's also something of a vindication against the meh-force and it is useful to get reinforcement for my sense of what is valuable to architects. Shaping how we view what we/architects do, and how to approach and do our work, is not nothing. ;)

5/29/16: Well, how about that? Downloads ticked up to 84! And 14 likes, including Kris Coverdale -- thanks to Kris, and everyone else who gave a visible "hat-tip" in the form of a Like!! I'm not sure why people who download the slides don't tend to Like them on Slideshare. Anyone have any ideas? I mean, if they're good enough to download, why not say thanks with a Like? I feel like some kind of super-WiT, going round reminding people about the Golden Rule on social, but I think we just forget that there are real people behind the resources we take advantage of -- whether it's open source libraries, video instruction, writing, ... All these things that take time, talent, insight. Unless we remind ourselves to say something when we feel grateful (and remind ourselves to be grateful when we find something worth our while, and take it), we quell that expression, that voice. It can only last so long in a vacuum, or almost vacuum.


Some Notes on Advocacy

Advocacy, framing someone's work in the positive, encourages that person, giving them reinforcement for their own sense that the work they are doing is meaningful. And it gives other people a heads-up on good work, helping them find out about work that may be useful to them. And when it's about me, it helps me develop cred. Given my contributions to this field over the past 20 years, I should have truckloads of cred, of course. But a WiT (women in tech) has to face a constant battle -- in every new situation, we have to work from unconscious bias that puts us at a (researched and documented) disadvantage. Positive word also helps reach new clients. It's lovely working with the same clients year after year as we do, but it's also great to get to work with other organizations, their teams and challenges. Which I only say, because even I can forget, in the joy of just sharing what I've learned and am learning, that I also need to pay some attention to getting word out about the business that pays the bills. We don't want to hear people giving a marketing pitch, least of all a pitch for themselves as their "product," but sometimes we just need to remind ourselves who we want to still be around. We need to shop local enough that we keep local businesses around, and don't shove them all under the Amazon-UPS truck... If we value someone's work, we need to mention it sometimes, increasing awareness of their work, and social signaling that there is goodness in their work, so they keep having opportunities to work. We don't want to talk about the grimy fiscal realities or do market-y stuff. But mentioning what we value or found interesting serves ourselves (we notice more what we're noticing!) and others. It's a virtuous cycle. ;)

Early on, someone asked me why I quote and otherwise include other people's thinking so much -- the point being something like: why am I deflecting attention from me by giving it to others; why not take the attention I have earned through experience and reflection? If I had to choose, perhaps I would far rather share the lineages of my thinking than some insight I've reached in any present moment. But I don't have to choose! Where I can include others to make a point I am trying to express, then I do! It enriches my experience, and others too, right? It weaves a net of ideas and their people, adds their color, as well as their insight and nuance. And I'm still the person who saw how what they did can be threaded into and built on, to make a more powerful insight. And so it goes.

We each have a super power that is distinct from everyone else's -- the excellence we have developed within us. I think mine is how I see. Noticing. Connecting. Making something altogether new, and yet with a history. Oh, I have gobs of background that helps -- from graph theory, linear algebra, stochastics and dynamic programming, to a deep coding career that started with Starting Forth and embedded systems, to working in and leading teams, to systems design and architecture, to strategy, ..., to literature, ... you get the picture. :)

Anyway, the distinctness of what we each offer, means we best view ourselves as potential complements and contributors, not definite competitors.

just collecting cognitive dew to make an insight well


Upcoming Open Enrollment Architecture Workshops

In a recent email (4/15/16):

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


More about what we do:


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


- 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:May 55, 2016
Last Modified: June 10, 2016