A Trace in the Sand
by Ruth Malan
Here is the description for my workshop for the Software Architect Conference in London. Please
Parkour for Architects: a requisite variety workout
Our trajectory towards becoming software architects involves writing code, creating and evolving systems. Important, certainly, but it does beg the question – what else, what other areas do we need to develop (further), in order to be (more) effective as architects? And how do we ramp up those skills? So, we will explore a “Parkour for Architects” from two points of view:
The following is our terrain map:
The exercises are fun and challenging, and they're chosen for their relevance to understanding and doing architectural work -- the direct work of architectural design and/or the indirect but essential work of making the architectural design effective and ultimately successful.
It is just a day, but we will exercise skills in each area, giving a sense of what it takes to reach the next level of fitness.
Hm. Should I mention that I have been working with architects (is "professional trainer for architects" taking the fitness metaphor too far? ;-) for close to two decades? Or does that make me look old... I mean... totally like an Olympian level person to work with as a coach and trainer for architects? We used to do this workshop designed around the competencies described ever so well (that's a smiling wink at marketing speak) in What it Takes to be a Great Enterprise Architect. But I wanted to do a refresh in that space, and redesigned the workshop around domains of effectiveness that are especially significant to architecting.
Here's a note from when we first came up with the effectiveness backbone:
* One might want to note that self-organizing is a way of getting things done.
From time to time we get push-back on why we include this or that capability (in the earlier architect capability model, or the domains of effectiveness/"terrain" model above)... on the grounds that this soft skill or that technical skill is applicable to other roles. Well, with that argument, it all dissolves. Everyone does design (at some point, in some form). Everyone makes decisions highly critical at their scope or locus of contribution. Everyone has to work in a work world with other people. It is more a matter of what, for the architect, takes significant time and attention, sensibility and acuity, and so forth, and what has critical impact on success (not just right system built right but all the other factors that mean the system is delivering sought outcomes, including sustainability in all its forms from technical and operational to economic and environmental). This may not be unique to the architect role, but is uniquely focused or shaped by the concerns and responsibilities of the role.
The model identifies architect capabilities and characteristics. Some may be defining characteristics of architects, and some may apply to other roles, but be more piled up with demands on the architect whose role is about broadly scoped strategically impactful and/or structurally significant decisions that affect system and system-of-system outcomes and hence have organizational or people ramifications. The idea is that architects can use the model to identify capabilities they may want to enhance in themselves, to better serve their teams and broader organization.
When one has been heads down in the doing of writing code, it is useful to have a heads up to the broader slate of concerns of, and demands on, the architect who has to work across the system -- across teams and focus areas. It is challenging in new ways that may be distinct from designing at more local scopes, or may be simply the more challenging, because more and more agendas and turfs are impacted, the more broadly scoped the architectural work. Sure, this is true of management roles, but also quite different. The decision set is different. The collaborative and participatory demands are different. Etc. Etc. If one just stops to think about it, I think it becomes clear that though design, or politics, or consulting, or whatever, applies to other roles, the way they pose challenges for architects differs in degree or content or focus, and there are also different competing demands on the attention of, and challenges faced by the architect.
Let us take, for example. consulting. The architect acts as a mentor and coach within the team, helping to identify and resolve design issues, and pair programming and otherwise sharing coding know-how, -when and -why. The architect also consults with the management team (at the architect's level of scope -- e.g., product management for a product architect), on project resources -- just kidding! But helping management understand project needs. The architect is an advocate for the team among the direct management team -- providing the necessary counter-force to schedule pressure to ensure that adequate attention is paid to design integrity so the code doesn't fall into debilitating technical debt. The architect also brings understanding of technical opportunities and consequences of strategic alternatives to strategy setting explorations and decisions. A technology "roadmap" (projections of relevant and tantalizingly almost-relevant technology trends) is a strategic deliverable, and it is used to inform strategic discussions with management. If technical marketing is doing this work, the architect can simply collaborate. Very often no-one has any idea that maintaining a "technology radar" or trends/projections map that is specific to the product or service area is even a thing. Because who is thinking about architecting being a strategic role -- or thinking about businesses relying on technology, and software, to build competitive distinction? But they need to be thinking in these terms! And architecting is as strategic as the architect makes it -- with or without permission.
Thus in the area of consulting, on the one hand, there is technical consulting that draws on the technical content of the architect's work and background, but has to do with helping the team(s) work with the architecture and to raise the level of code craftsmanship. And on the other hand it has an element of management consulting -- bringing insight into ramifications and alternatives and ideas, to the project and strategy table, helping with cultural/organizational change initiatives, etc. The technical facet is defining, and what most people expect of the role, but the strategic and organizational facets make or break the technical dimension.
The What it Takes to be a Great paper is still a very fine piece of work and well worth the price of your contact information -- or you could buy it through the Cutter store. ;-) (They did that amazing thing -- got me to write those 4 papers. So you have to know the Cutter editors are incredible!)
Every paragraph wants to grow up to be a book! ;-)
[I should add... "architect" is used variously. In some organizations, architect is used where the same scope of responsibility in another organization would be called a tech lead. So. Judgment factors. The bioader the scope (systems of systems, very complex systems, etc.), the more senior and hence more strategic the responsibility set. It's all more contextual than a few paragraphs can detail...]
Well, several people were really nice about the workshop proposal so I'm coming back for more. I need to turn in the abstract for my presentation (at the same Software Architect Conference) -- suggestions welcome. Encouragement too. And I already know about the rotten fruit thing, so we'll have Robert Annett running interference on that and I'll be totes fine. ;-)
Okay. Your feedback please:
Design Visualization: Smoke and Mirrors
Short form (they need 80-90 words -- so I have more)
Architecture includes the design of the structures and mechanisms that yield system capabilities and properties, and visual expression is a key medium for intentional design. We also say that “every system has an architecture” -- though for many systems, the only expression of this architecture is in the code. We will consider design visualization in terms of (to put it playfully) "smoke," presenting design intention, and "mirrors," reflecting the system design as built. We will use a map of the visualization landscape to identify and distinguish the various forms of software visualization, discuss what each representation is good for, and identify gaps and implications.
Architecture includes the design of the structures and mechanisms that yield system capabilities and properties, and visual expression is a key medium for intentional design. We also say that “every system has an architecture” -- though for many systems, the only expression of this architecture is in the code. We will consider design visualization in terms of (to put it playfully) "smoke," presenting design intention, and "mirrors," reflecting the system design as built.
We will reassess what we’ve learned about sketches, diagrams and models in system design. And we will explore reflection of the design implicit in the code and system in operation, using tools for "extracting" and presenting various design views, or other visualizations with implications for the design. We will use a "map of the visualization zoo" to locate, identify and distinguish the various forms of software visualization, discuss what each representation is good for, and identify gaps and implications for improving our design work and our systems as we evolve them.
These are some notes from earlier (by several years) Traces:
Oh my. That was rather long ago. Three cats became two cats... became one cat... became one cat and a kitten the other day. It really is time I got that visualization work updated and set loose upon the world.
Oh, right. The "map of the visualization zoo" refers to a piece of work I did back in 2010, but obviously visual design has been an ongoing focus (visual architecting and all that) and software visualization is an important component of our approach. I do need to update the "zoo" with new species that have emerged since 2010 though.
Thanks to Brenda Michelson, Peter Bakker, Sally Bean, Cory Foy and Amitai Schlair for suggestions and encouragement -- again, if you're not already following them, please note their awesomeness and follow them.
I framed and contextualized the talk as follows: "Architecture includes the design of the structures and mechanisms that yield system capabilities and properties, and visual expression is a key medium for intentional design. We also say that “every system has an architecture” -- though for many systems, the only expression of this architecture is in the code."
Let's take the first sentence there. Is it redundant, given what we understand architecture to be? First, this is a field where we slid visual models quietly under the rug with BDUF in the wake of the Agile Manifesto (and the binary tendency to land entirely on "working software" when the alternative -- "comprehensive documentation" -- is, frankly, patently not Agile; the wording there is a tip of hand; don't kill me for saying so). Second, there is a lot of uptake for the notion that "architecture is a set of decisions" (the hard or architecturally significant decisions). Clearly it is, but when we throw our weight there, we pull out an architecture decision template... More sliding models under the rug. When we keep our emphasis on architecture as strategically and structurally significant design (which entails decision making), we keep structures (including relationships) and mechanisms (the "how it works" dynamics) in play. I think this is important. It is not all. But it is an important part of architecture and hence architecting. So, with my framing I wanted to do a reset. Smuggle a donkey? Sure. But an important one that carries the weight where I want it to go. ;-)
The second sentence gets at the visualizations that serve as "mirrors", or reflections of some or other design aspects or characteristics of the system that have implications for the design. Of course there are caveats about how much of the design can be extracted from the code.
Oh, and a quick word on why I jumped at the "zoo" metaphor (used by Jeff Heer et al in "Tour of the Visualization Zoo") for the work I did on characterizing the software visualization landscape. (Grady Booch and I were collaborating on identifying what was going on in software visualization, so while he can't be blamed for anything I got wrong in the visualization zoo (rats, huh), our conversations and sharing of links were important to its creation. Also, the layout of the zoo borrows from visual architecting, so Dana Bredemeyer had some complicity... I mean deserves to share credit for that. ;-) Enough background.) There is such a variety of "beasts" out there in the visualization space, a zoo seemed like a fun image -- corralled understanding of what appears in the wild, held captive for view. That sort of thing. ;-) And I wanted to draw a clear line of reference back to that Jeff Heer paper, which is also influential.
Well, since I've come this far, I should say a word or seventeen about the title, and specifically why I dug my heels in about smoke and mirrors, despite very good ideas for alternatives? Well, partly it has intrigue -- does Ruth really mean design is a smoke and mirrors kind of game? ;-) And partly it is key to the plot of the talk, so is a colorful synopsis and agenda setter.
Everything is more than it seems (with me. As it is with you. And everyone. Well, everything. Really).
Speaking of more than it seems... I'm glad at least Jessica Kerr (and Sally Bean, in a different context) got this one. It's like this, but maybe better? It's like a prose poem for architects and (other) innovators. It condenses volumes into (a very chewy) 140 char(red) bite. I'm over-doing the self-cheerleading (and self-denigration)? Oops. But... but... I've been doing this stuff for 20 years and do you see anyone else cheerleading? No? So I get to? Oh, you're so kind. Thank you. ;-)
I looked back at the very out-of-date map of this Trace, and was stunned by how many entries there are under Visual Thinking and Visual Design. That map covers the first several years of this Trace so isn't all that useful any more, except as a (emphasis on a -- it's not complete, nor the only one) survey of what this architecting discipline covers. And such topics! "Let's repair the relationship"?!?! ;-)
I also write at:
- Bredemeyer Resources for Architects