A Trace in the Sand
by Ruth Malan
I'm going to give Twitter a break (with some exceptions), and (with some exceptions -- e.g., below) stop tracing again. I have so much work to focus on. It's exciting!
To get a sense of what this Trace was, here is a selection of traces collected by topic (roughly 2013 - March 2014). It was unusual, I'll grant. But in a field where we talk about empathy, vulnerability, trust, joy and kindness, it was those things and more. Where we talk about "bringing our whole self to work," it's been doing that for nine years. Well, of course there were the usual architects architecting architecture topics too. The usual topics, with field-leading, boundary-pushing insights. You think that claim is overblown? Well, you'll have to read some traces then, to see for yourself. Try this one -- it packs more than the usual payload of insight into just a few words and a couple of diagrams: Contexts
"Attention is the rarest and purest form of generosity." -- Simone Weil
Anyway. I hope you'll join me. Let me know when you sign up, so I can be duly terrified. Ha! No, I mean, so I can let you in on the secret preview group.
* By senior, I mean broad scope of responsibility (complex systems, product lines, product or service portfolios, etc.), with high strategic impact. The broader the scope (leading and influencing many teams), the more demanding the role in all its dimensions -- organizational, technical, strategic, and personal. The technical decisions are of high consequence -- that is a defining characteristic of architectural decisions. If they're not, you wouldn't/shouldn't be involved in and ultimately responsible for them. They set direction, enable and constrain the business -- so senior architects had better have a keen sense of the strategic. They have impact across various "turfs" with their own purview and agendas, so the "political" aspects cannot be ignored -- or are, at the peril of the teams who depend on senior architects to help create and ensure the context for teams to be successful and thrive.
** Another word about product owners and the like: "requirements" are design decisions that have to do with what role the system plays in its use contexts, and these include highly architectural decisions -- what responsibilities are shifted from the context (persons or other systems) to the system, for example, is about boundary design (what's in, what's out). In that view, decisions about system capabilities and properties are architecturally significant for the system, and its containing systems. Not everyone will see it this way, and I don't belabor the point (except when I do ;-), but I simply wanted to open the invitation to other "flavors" of designers with the caveat that the technical core is different for software architects, but the system thinking translates well to other kinds of systems (social, and socio-technical, not just technical).
9/3/14: It'd be awesome, especially if you haven't done so already (thanks to those who have), if you could pass on word about the conference and my workshop. It costs a lot to haul me over to London, and the organizers have to commit to conference space and all that. When the economic climate gets a bit jumpy, we have to pull harder to keep the ship moving. Be excited about the conference, and my workshop in particular, okay? Thanks. Much appreciated!
“Attention is an intentional, unapologetic discriminator. It asks what is relevant right now, and gears us up to notice only that.” -- Alexandra Horowitz
Distributed development of systems is both hard and a way of life for global companies. I'm pulling together a report of what we've learned on what makes that hard and what to do about it. I am happy to share it with those who participate, so if you're interested in sharing experiences please let me know.
Parcour: Some More
This from Tom Graves (are you following @tetradian -- I hope so! If not, fix that, why don't ya? Tom is one of the most generous thinkers and coaches in our field, sharing his wisdom in countless ways.):
Ah, yes, the technicalities of making the best use of it! Also, in our case (architecture), we are sorely behind on the education part, for designing complex software systems is not part of typical CS or SW Eng undergrad programs.
As Tom Graves indicates, The Art of Scientific Investigation is highly pertinent (with particular relevance to the personal domain of effectiveness -- e.g., intuition, imagination, curiosity, productive thinking, .... --- in the parkour map, although there is some overlap with other areas too):
I also write at:
- Bredemeyer Resources for Architects
My avatars look even more like me than I do, but conferences tend to want the less representative version: