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. It's a rare opportunity for me to work with you. Nations are getting more and more restrictive and it is becoming harder to share expertise directly and work across borders.
* 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):
From an email:
Well... It's like this see... Architecting is what architects do. We just try to help do it better. In the absence of a name, clients were calling what we do "the Bredemeyer Process" and that was even further in the wrong direction, so we called it visual architecting to put the emphasis back on visual (in the early days of Agile, when things modeling and visual were being swept out by the anti-BDUF wave). The sketching (informal systems modeling) we do is important --"a picture is worth 1000 words." But only 1000 and we need to add words too. So, a little lesson in architecture, from my twitter soapbox:
The story of James Madison as architect of the US Constitution is told here: What it Takes to be a Great Enterprise Architect, 2004 -- yes, you have to pay the price of your contact information to get a great report (think free ebook). If you were paying by credit card, you'd be risking more data than that. ;-) We owe a lot to the Cutter editors -- not least of all, for asking us to write the executive reports, and encouraging me. When you're just trying to get solid work done, you don't make it above the attention surface of this field, and no-one is going to know about the work. So much is owed to those who notice, and encourage, and share, valuable work.
The architecting process, like "the peace process" or "the scientific investigation process," is a way, way different nature of process beast than a chemical process used in manufacturing where unit operations are carefully defined and staged. We have heuristics and principles like the "this extraordinary moment" principle (which is owed to Bucky Fuller, by way of Dana Bredemeyer who articulated it as a guiding principle for architects):
Back to Focus Focus Focus
When I have something to show, I'll pop back up. :)
Of course, sometimes I'm reminded of some good work I want to give exposure to, or something else in the community needs some support. Like that Software Architect Conference -- bringing me from the US raises their costs.
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: