A Trace in the Sand

by Ruth Malan

 

 

 

 

Architects Architecting Architecture  

June 2015

6/15/15

Trace?

6/22/15

What Ya Think?

Here is the description for my workshop for the Software Architect Conference in London. Please tear it to shre I mean, give me suggestions on how to make it even better. :-) (It will be on October 13.)

 

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:

  • what does each “fitness” area work out, and why are we focusing there?
  • exercises in each area, doing the program of workouts in small teams

The following is our terrain map:

  • personal: foundation attributes like perception and bias, empathy, creativity, problem framing and solving, focusing on new or more challenging aspects of the architect role/responsibility set
  • organizational: interpersonal skills like leadership, collaboration, communication and influence, focusing on getting things done in organizations
  • technical: architectural decision making and system design, focusing on the unique demands and challenges of architectural design and what it takes
  • strategic: business and technical strategy, focusing on impacting, setting and evolving (technical) direction

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.

effectiveness

Aside:

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:

Organizational effectiveness is about getting things done*, when they are too big to do oneself. While we place leadership, consulting, and organizational politics under organizational effectiveness, it surely overlaps with the personal (in areas like empathy). None of these divisions are clean. For example, creativity may fall under personal effectiveness, but impacts strategic effectiveness and technical effectiveness. If we say that "making decisions (stick)" falls under leadership when the decisions impact (many) other people, the making decisions part may be strategic and technical, but the "stick" (as in enacted) is the organizational part, especially where much must be achieved through persuasion and influence rather than formal authority (and the other kind of stick, equating to punishment [an observation, not a recommendation]). [I must remember to get a ceremonial feather for the skills workshops. ;-)] Chris Argyris' work would lead thinking in personal and organizational effectiveness areas. Russ Ackoff's work has more to offer in the organizational and strategic effectiveness areas, as well as "technical effectiveness" if by "technical" we include social and socio-technical systems design. And so forth.

* One might want to note that self-organizing is a way of getting things done.

 

Gratitude

Thanks to Sally Bean, Brenda Michelson, Robert Annett and Gene Hughson for suggestions and encouragement -- if you're not already following them, please note their awesomeness and get on it already!

 

6/30/15: Getting Past "But that just applies to everyone"

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...]

 

6/25/15

And Next: How's This?

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.

Longer form:

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.

smoke and mirrors

Aside:

These are some notes from earlier (by several years) Traces:

I think of software visualization in a "smoke and mirrors" kind of way--which is to say, we use software visualization in design, visually modeling the intended design, and we use software visualization to reflect aspects or dimensions or abstractions or views of the code.

That is, we visualize software to be, and we visualize software as built. And there is also visualizing, for example, the social interactions that took place over the life of the system, giving insight into the relationship between the human society building the system and the society of components they build. But I wouldn't want to exclude envisioning or design from the field, because there should be a relationship between what is envisioned and intended, and what gets built and hence reflected--where we have both sides of that coin, for example in Lattix or CPPDepend/NDepend, we get the distinct value of catching deviations from the design early, so we can assess how to respond (does the design need to change, or the code) before dependencies grow into giant hairballs too big for human cognition to digest... or something... (we have 3 cats, and it's spring; need I say more?)

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.

 

Gratitude

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.

 

Observations

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

- Trace In the Sand Blog

 

 

 

Journal Archives

- Journal Map

- storylines tubemap by Peter Bakker

 

2014

- January
- February
- March
- April

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

2013

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

2012

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

 

2011

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December

 

More Archives

 

 

 

I also write at:

Papers:

- Strategy, Architecture and Agility: The Art of Change: Fractal and Emergent, 2010 

- Innovation and Agile Architecting: Getting Past ‘But’: Finding Opportunity and Making It Happen, 2008

- EA and Business Strategy: Enterprise Architecture as Strategic Differentiator, 2005

- The Role of the Architect:: What it Takes to be a Great Enterprise Architect, 2004

 

Ruth Malan has played a pioneering role in the software architecture field, helping to define architectures and the process by which they are created and evolved, and helping to shape the role of the software, systems and enterprise architect. She and Dana Bredemeyer created the Visual Architecting Process which emphasizes: architecting for agility, integrity and sustainability. Creating architectures that are good, right and successful, where good: technically sound; right: meets stakeholders goals and fits context and purpose; and successful: actually delivers strategic outcomes. Translating business strategy into technical strategy and leading the implementation of that strategy. Applying guiding principles like: the extraordinary moment principle; the minimalist architecture principle; and the connect the dots principle. Being agile. Creating options.

Feedback: I welcome input, discussion and feedback on any of the topics in this Trace in The Sand Journal, my blog, and the Resources for Architects website, or, for that matter, anything relevant to architects, architecting and architecture! I can be reached on Twitter: @ruthmalan.

Visualization

- Links to tools and other resources

 

 

 

 

 


 

Ruth by West

Copyright © 2015 by Ruth Malan
http://www.ruthmalan.com
Page Created: June 3, 2015
Last Modified: June 30, 2015