A Trace in the Sand

by Ruth Malan

 

 

 

 

Architects Architecting Architecture  

October 2015

10/24/15

Design Visualization: Smoke and Mirrors

Below are the slides from (Part I and the first section of Part II of) my Design Visualization: Smoke and Mirrors (90 minute) talk at the Software Architect Conference in London on October 14, 2015. The notes alongside convey the spirit of the talk, but while rehearsed, I didn't follow a script. (I didn't even stand where I could see my speaker's notes, because that would have put me behind an obstruction and way out of contact with the audience.) Anyway, the talking points are, for the most part, close to what I said. Well, I did take some artistic license here and there, expanding some of the points. Just a smidge. ;-)

 

Part I: Introduction and Software Architecture

Design Visualization 1

This is the part where I tell you "This flight is going to Indiana by way of South Africa. If you're on the wrong flight, this would be a good time to attend one of the awesome talks down the hall."

My name is Ruth Malan -- I don't know how to pronounce it either, so any way you say it is fine. 

Well, as long as you're staying, let me tell you that Dana Bredemeyer says "There is a silver bullet in software engineering, and it is relationships of goodwill and a commitment to objectivity." There's a catch though. Those relationships take effort and attention to build and to sustain and grow.

So here I am, relying on you to extend a little goodwill on credit to me, and as we proceed, I hope I'll earn a little more, as we talk about some ways we can work on objectivity.

 

The M.C. Escher Company holds and protects their copyrights to M.C. Escher's work quite tenaciously. Not being able to reproduce Day and Night for you here, presents a little opportunity to demonstrate a point at the heart of this talk.

Day and Night is one of Escher's more famous works, so you have likely seen it and I'd like you to call it again to mind. Do you see it in your mind's eye? It is the one where there is a town in the light, and a mirror image in the dark of night. A river runs by, in the light, and the night. There are fields that become abstractions that become duck (or geese), flying <gestures a mesh with interwoven fingers of both hands> from the light, others in mirror image out of the night.

When you called it to mind, perhaps at first you were thinking of another Escher, or perhaps it struck you differently and you remembered different features. And that's the point, really. We don't know if what I call to mind, and see in my mind's eye is quite what you see, even if the original was the same image.

Another point of salience in this context, is that it conveys a movement, a fluid interplay, between the concrete and abstract, between what is and what is mirrored.

And that is where we are headed -- to talk about design as intention, and reflection of design as realized, and how we express and envision our designs. But first I would like to revisit how we think of software architecture, and the role visual expression plays in design.

 

I playfully subtitled the talk "Smoke and Mirrors" -- for it can seem like we practice magic and sleights of hand when we don't expressly communicate our design intention, or reflect on the design as realized, in order to iterate on and improve our understanding of what we have, and intend.

 

Here we have the definitions of intention and reflection from Ambrose Bierce's Devil's Dictionary. If you're not familiar with the Devil's Dictionary, it gives definitions a cynical side-eye, helping us understand something better by looking at the (negative) space left by contact of the concept with reality, and what that defines. Intention, then, is what we get, despite our intention -- an involuntary act. It is a big wink at our bias and foible and self delusions and intellectual aggrandizements.

As for reflection: "An action of the mind whereby we obtain a clearer view of our relation to the things of yesterday and are able to avoid the perils that we shall not again encounter." That so well captures the weltanschauung of our day and field -- we forget, of course, that it was Heraclitis who said "Change is the only constant."

Now, when it comes to definitions I'm on the same page as Richard Feynman when he said: 'We can't define anything precisely. If we attempt to, we get into that paralysis of thought that comes to philosophers… one saying to the other: “you don't know what you are talking about!”. The second one says: “what do you mean by talking? What do you mean by you? What do you mean by know?”'

Undeterred, we're going to take a look at the definition of software architecture.

This is the definition from the touchstone of our era, wikipedia.

When I see a definition, especially in a context like this, I tend to see it as words words words.. words words. So I helped a little to lead attention from software architecture to system.

What do we mean by system?

 

Dana Meadows characterized a system as "an interconnected set of elements that is coherently organized in a way that achieves something."

 

Returning to Paul Clements and colleagues definition on wikipedia, we note "high level structures" -- comprising elements and relations, along with properties. High level?

Grady Booch memorably observed "All architecture is design, but not all design is architecture. Architecture represents the significant design decisions"

Decisions?!

We know what to do with decisions! We'll name them, describe them, identify what problem the decision addresses and the forces we're weighing to harmonize, resolve and balance. We'll keep track of assumptions we're making, explicitly identifying what in the context we presume to be stable and what to watch. We'll connect the dots to the business rationale and technical goals we're trying to achieve, or the hard-(l)earned scars of experience we're seeking to avoid this time round. We'll outline alternatives we considered but ruled out, so we don't have to revisit those arguments again and again. And we'll note implications so we -- our teams and those we collaborate with -- can be prepared. Then we'll consider what further requirements are implied by, or derive from this decision we're making and documenting. And identify related decisions we need to make next...

Decisions are central, and it is a great template, but you can just hear the captain in the cockpit yelling "pull up, pull up" -- we'll run into a veritable forest of decision trees if we speed too far too fast down that runway just now.

Which decisions? Design decisions. Design!
Herbert Simon, according to Jabe Bloom, is "ground zero in design discourse." And this is quintessential Herb: "Everyone designs who devises courses of action aimed at changing existing situations into preferred ones."
A variation on the theme: "The engineer, and more generally the designer, is concerned with how things ought to be - how they ought to be in order to attain goals, and to function."
And that is just one of those so precious moments when the world is full of simple wonder again -- we design to get more what we want.
Returning to the eminent Mr. Booch: "Architecture represents the significant design decisions"

"What decisions does the software architect make?"

The architecturally significant ones.

"What is architecturally significant?"

The architect decides!

The architect decides. That sounds like a tautology, but it really is the crux of the matter.

Is this the part where we get to talk about technical wisdom?

No, this is the part where we get to say "Awww"

Just kidding.

Technical wisdom factors. Factors in and factors out. What is shapingly crucial?

Ok, so if architecture is a set of decisions, but not all decisions, and we're asking which belong in the architecture, we're looking for those that shape, that

  • give form to the system
  • set direction
  • constrain
  • bring integrity and consistency

And those that have the highest cost of change. Decisions which would incur substantial

  • resources and time
  • operational downtime
  • deferral of value
  • emotions and politics

to change or revert and rework, are architecturally significant.

Also, if a decision meaningfully reduces the cost of making changes, enabling our business to be more fleet, adapting and extending its services or product set as the market shifts, it is architecturally significant.

Those are important insights, but I would like to add: architecture decisions are structurally significant. They deal with the organizing structure of the system and the design of architecturally significant mechanisms to yield desired system outcomes, including system properties, while addressing inherent challenges. Structurally significant. You know, make or break.

And strategically significant. "Software is eating the world" (Marc Andreessen). Software enables. And more, across industries, software is increasingly a source, if not the source, of differentiation. It is game shaping and game changing.

 

Software systems are in place -- for 3 months, 3 years, 10 years. 20. Because they enable something our business depends on. But, increasingly, and more as systems age and the architecture erodes under the weight of accommodations and agglomerations, these systems constrain the business, impede agility and adaptability and responsiveness to an ever shifting context.

And architecture, the critical decisions that hold the system up and tie it down, in turn enables and constrains the code (and those who write it).

Architecture decisions create the context for further decisions, reducing -- cleaving -- the decision space. This is good. It reduces the overload of overwhelming ambiguity and uncertainty, creating "ground under the feet" (Dana Bredemeyer) that we can move forward on. Critical decisions take time to make attentively and can be fraught with downstream consequences if made inattentively and without foresight. And this is bad, if it takes decisions away, reduces empowerment or degrees of freedom and motivation, where it matters. So we seek to keep our architecture decisions, in Dana Bredemeyer's urging, to a minimal set.

To reach a helpful notion of what, then, we consider architecturally significant, Dana points to Daniel Day-Lew--er(r) Abraham Lincoln:

"The legitimate object of government is to do for a community of people whatever they need to have done, but cannot do at all, or cannot so well do, for themselves, in their separate and individual capacities. In all that the people can individually do as well for themselves, government ought not to interfere."

Architecture decisions are those that impact system outcomes. That is, outcomes that can't be ascribed to locally-scoped parts of the system. Intentional architecture decisions are those, from a standpoint of experience, we deem must be made from a system perspective, to get more what we want from the system. More than we would get, if we left the decision to be made at a more narrow scope with only local information about the forces that impinge upon, and outcomes that are contingent on, the decision.

That is, architecture decisions are those that need to be made across boundaries -- the system boundary, and boundaries within the system, in order to achieve desired system outcomes -- to meet system goals with more the system properties we want. Properties like usability or performance that the user cares about. Properties like resilience and scalability that the ops team cares about. Properties like understandability and adaptability that the dev team cares about. Properties that emerge from interactions and relations among elements, rather than localized concerns.

Of course, despite our best intentions, some implicit decisions will prove to be architecturally significant. The point is, do we want to leave matters of system integrity and strategic import to accident, or do we want to bring what we can to bear, to get more what we want?

 

Part II: Visual Design; Section A: Leonardo da Vinci and the case for sketching

When I googled to find an image of Grady for the previous slide, this was one of the results. It's on an IBM site related to a conference, and next to the image of Da Vinci and Booch there is the playful caption "separated at birth?" The relationship, at least in my view, has to do visual design, for Grady Booch is one of the fathers of visual design in software. While Leonardo da Vinci is one of the fathers of visual design in engineering.

Anyway, I thought the image was a neat serendipity because when I was collaborating with Grady Booch on software visualization several years ago, Grady introduced me to this book: Engineering and the Mind's Eye. Which in turn introduced me to Da Vinci as engineer. Of course, I was familiar with Da Vinci's work as artist -- even privileged to see his cartoon (as a full-size preparatory study for a painting is known) of the Virgin and Child (with St Anne and St John the Baptist) in the National Gallery. I'd seen his sketches of imaginative flying machines and was aware of his notebooks.

But I hadn't explored the extent, manner and contribution of his work in engineering.

Now this Renaissance man would be inspiring in any event, but additionally so in this context, for he used sketches to investigate, to find out, to create visual "demonstrations" that teach.

He puzzled things out, to astonishing effect. Da Vinci foreshadowed Copernicus by 40 years, declaring "IL SOLE NO SI MUOVE" ("The sun does not move.") He added, "The earth is not in the center of the circle of the sun, nor in the center of the universe." And 200 years before Newton, he wrote "Every weight tends to fall towards the center by the shortest possible way." He was likewise prescient in other fields. 400 years before Darwin, he placed man in the same broad category as apes.[Gimpao Ni Ei Suuh]

We may know him as a painter and sculptor, but he was esteemed in his day not just for art—holding official positions as engineer including "painter and engineer to the Duke", and “First painter, architect, and engineer to the King.”

Leonardo was intrigued by problems like inertia, friction and resistance, and investigated mechanisms and mechanical elements such as screws and gears, pulleys and weights, with a piqued visual curiosity. Though his scientific notes are articulate and precise, for Leonardo, illustration took precedence—the drawing does not illustrate the text; rather, the text serves to explain the picture. To this end, he developed principles of graphic representation—stylization, patterns, and diagrams.

Indeed, he developed and practiced a rather modern form of cognition—studying what was known from masters current and past (his library was extensive), but extending that study by "knowing how to see" (saper vedere) with scientific inquiry augmented and abetted by technology—that of pen/pencil.

He and other engineers of the day would study each other's works.

And they copied designs from each other's notebooks (Engineering and the Mind's Eye).

Leonardo's notebooks capture and extend understanding of phenomenon of nature and machine, and include numerous inventions, some built in his time, others later -- such as the lens grinding machine pictured.

These inventions, we might note, were constructed as sketch-prototypes so compellingly drawn as to both persuade feasibility in many cases, and to inform construction. (The Archimedes steam cannon is a fun story).

Leonardo's notebooks stand testimony to sketching as a means to

  • observe more closely
  • study, think, reason
  • record, not just to persist, but to extend the range of cognition -- one's own, and also to communicate with and teach others
  • invent, by making novel connections
  • test ideas on paper
  • persuade

When it comes to using a pencil to see, there's another story of a great teacher I'd like to share. This story is told across fields from that in which it originated, to sociology, literature, even systems architecture. When new students came to study natural history with Louis Agassiz, he famously had them study a fish. A dead fish. A dead fish smelling of the alcohol it was preserved in, and into which the student had to return the fish at breaks or before going home at the end of the day. A day spent... looking... at the fish. Without tools to magnify or dissect it. Each student simply had to study the fish, without direction. No guidance on what to look for, what to study. Without distraction. For days. On end.

The indelible lesson? Was one in observation. Observing the structure. Forming hypotheses about the relationship of structure to the functions and behaviors the fish would have had, alive. Several of Agassiz's students tell similar stories, one recounting that he'd picked up a pencil to draw the fish, to sketch details and Agassiz had remarked "That is right, a pencil is one of the best eyes." But those seeming endless days of looking -- seriously observing, studying, patiently formulating understandings, was a lesson students pointed back to as career-shaping. As they came to see more, they'd get more from Agassiz, but the training was in learning to see. To see, to understand the fish. Its structure, its symmetries, the relation of structure to function.

Centuries before, Leonardo da Vinci had studied human anatomy with the same emphasis on "knowing how to see" -- especially with the aid of a pencil or pen.

This is from the Encylopedia Britannica, which I reproduce because the language is telling: "Leonardo combined anatomical with physiological research. From observing the static structure of the body, Leonardo proceeded to study the role of individual parts of the body in mechanical activity. This led him finally to the study of the internal organs; among them he probed most deeply into the brain, heart, and lungs as the “motors” of the senses and of life."

And from Martin Clayton's book on Da Vinci's anatomy work: "First of all, as a sculptor, engineer, architect, he had an intuitive understanding of form — when he dissected a body, he could understand in a very fluid way how the different parts of the body fit together, worked together. And then, having made that understanding, as a supreme draftsman, he was able to record his observations and discoveries in drawings of such lucidity, he’s able to get across the form, the structure to the viewer in a way which had never been done before and, in many cases, has never been surpassed since."

The point that I want to draw out here, is that of sketching not only to see structure, but the relation of structure to function. The emphasis on understanding mechanisms by which parts work in concert to achieve some function or capability.

Leonardo 's studies of the brain were on corpses. Today we can study the brain structure and function while the person is alive.

Peering inside the head, while the person is thinking! Gaining a better understanding of what parts of the brain are active, when we are doing tasks of different kinds.

We're learning more, through visualization, of such deep and dynamic structures as the brain's pathways.

Now. No talk on visual design would be complete without the obligatory reference to the amount of the brain devoted to visual processing.

It's not my field and I don't know what is considered the definitive reference, but one source mentioned 30 percent and another 50 percent of the cortext is devoted to processing visual information -- the discrepancies being due, as I understand it, to visual processing being used in conjunction with other systems, such as the motor system, so it is hard to separate out.

At any rate, we are geared to take in a lot of the information we do, through our visual system. Advantage seeing over hearing, touch, smell, taste. Though smell plays a strong enough role to be the referent metaphor when code goes bad, and we seek to identify and remove code smells.

 

Of course, before we concede victory to those whoop-whooping at the advantage this confers on visual design expression, we might note that code is visual.

 

 
 
 
 
 
 
 
   
   
   

Part II: Visual Design -- halted in progress. Fully annotating the slides takes time (even though I've already prepared for and given the talk), which is hard to justify given the work we're doing, but I'll see what I can do. Some other rainy Saturday night. :-)

11/1/15: Excited yet? I wanted this talk to do something. I hope it was something worthwhile. ;-)

 

10/25/15

Twitter Furlough

I'm giving my twitter habit a hard reset. :-) I'll be back -- as a community bulletin board, a place to catch some curated tech news, and so forth, I don't know of anything that beats it.

 

10/21/15

True Story (and Parable of Our Field?)

Here's a true story:

I arrive at the hotel the night before my workshop. I check in. Go up to my room. The keycard doesn't work -- it registers, but with a red light and the door doesn't unlock. I haul my luggage back downstairs and explain to checkin. They give me the "lady over, what, 50?, doesn't get technology like hotel keycards" treatment. I tell them I tried several times (I really didn't want to go back down; really wanted that key to work!) and the red light indicates the keycard was reading, it just wasn't registering as the right key code for that door. They give me two keycards, and offer to send the conscierge with me. I decline. In my head I want to say "I've probably stayed in hotels more nights than you've worked in one," but I never want to actually be mean on purpose. Well, maybe sometimes, but it takes more than that. :-) Go back up. Try both keycards. Same story. Not wanting the same insulting "older lady doesn't get technology like hotel keys," I take a photo of the room number, and a photo of the number the checkin person had written on the key folder. Go back down. Checkin guy gives me the same treatment, making two new keycards and comes back up to the room with me -- he'll show me how to open the door. Lo. The door doesn't open with the two keycards he's brought. It does open with his master keycard. Hm. He apologizes and goes to get me another room and keycard for that. He goes with me to that room to make sure. He makes me use the keycard to check that I know how to use it.

Our expectations of women are low, and we have a really, really hard time hefting ourselves out of those low expectations. Everything I said, indicated that I knew what I was talking about. But he would not relinquish the frame that I was inept at hotel keycards. For crying out loud.

 

10/28/15

Adventure Journal

I found myself describing my Trace as an Adventure Journal, where the adventure is cognitive, exploring the landscapes of this field, and those that have bearing on it. I know, it has echoes of "What's a Trace?"? But perhaps I should put more emphasis on the "extreme sports" angle of the challenges this Trace puts its reader through. ;-)

Well, well. The traces that follow "What's a Trace?" (Contextualized, "Camp"-ing Out, and The Unit) are a nice representative taste of the way this journal works. It requires some suspension of (dis)belief (and judgment--of the judgy-critical kind) to get how it plays at the center and across the borders of bearing on our field. Hint: humor factors.

 

10/29/15

Tharp on Tharp

Last night we went to a performance by the Twyla Tharp Dance Company, and afterwards Twyla did A&Q--an inversion of expectations, as Twyla does. A&Q? Where she asked the audience questions, and responded to audience answers. In Yowzie (as explained by an audience member's answer, and amplified by Tharp) rejection spirals one of the tribe into devolution, or reverse evolution into an ape-like state. At the nadir of her fall, the tribe holds her aloft, in a posture that upholds and exalts her, and that is the turning point--giving her back a power and sense place in the tribe, and that heals her and she is able to rejoin the tribe, joyful and whole. Twyla has a wonderful way of seeing into (through?!) our humanity, and expressing it with a healing touch. In our field, we can be so much about "constructive criticism," the negatives accumulate into a weight that pulls a psyche under, and when we remember to give something back, to see the positive a person contributes, we buoy and uplift (thank you!) in a very real way. The biochemicals our brains release on rejection and acceptance make emotions physical. Sure, our mental constructions can act as accelerants or brakes, filters and shields, but social contexts do play an active role in creating/shaping experience. Dance is such a powerful visualization of what social creatures we are, and Twyla tells our stories with a canny and kind sensibility.

At the end, an audience member used the words "we have to fight for love," which Twyla echoed as her closing words. Which was interesting, because earlier in the evening I'd read Pablo Neruda's If You Forget Me, and I balked at the "if little by little you stop loving me//I shall stop loving you little by little" because it makes relationship too one-sided. Too "it's all on you, if this doesn't work." Love, of all kinds, not just romantic but collegial affection or caring, takes work. It is active--and that doesn't just rest on the shoulders of one. And, of course, Twyla does some of that too--inverting whose shoulders bear a load in gender dyads and triads, who gets tossed and caught.

Twyla made several (other) points that are important (to us), I think. One was that audiences have what it takes to get the abstractions and understand what is being conveyed by the dance -- the combination of dance, acting, music, costume, but most importantly the dance. I have so much resonance with that position. That is what art, poetry, dance expects -- that we can enter the space it creates, and expand our thinking to meet its creator and do our part collaborating with the creator to make a more shared, but also greater, meaning.

Commenting on someone's observation about [the greatness of the dancers'] technique and control, she said "we don't show you technique, we use it." Technique is the ground assumption, but it is always for a purpose, and the purpose is what unifies [controls] the dance [and dancers]. This "we don't show you technique," I relate to as something like "we aren't about bragging about, or drawing attention to, our technique. It is great! But we see technique as vehicle for the purpose we want to convey." Which I re-emphasize, because in our field we so often swashbuckle technique, forgetting that purpose is (should be!) primary.

Twyla Tharp.

And Wayne Shorter.

Redefine your notions before they define you!

 

10/29/15

Software Architecture Workshop

Good, right and successful FTW!

 

Systems-of-Systems Conference in Norway

Gerrit Muller sent us a heads-up that I'd like to pass along: Systems of Systems Engineering conference in Kongsberg Norway, June 12-16, 2016

I've never been to Norway, though Dana Bredemeyer has been many times. So, obviously I am looking to do a workshop in Norway in June next year. Any takers? ;-)

 

 

10/31/15

Grateful

My twitter alterego peeked to make sure I wasn't getting into any trouble (smiles!) -- thanks for the mention Amitai, and the very kind words Cory and Eugene and Henry! [They are clearly awesome, and you should use those links to follow them!! :)]

 

I also write at:

- Trace In the Sand Blog

- Bredemeyer Resources for  Architects

 

Architects Architecting Architecture'

 

Journal Archives

- Journal Map

- storylines tubemap by Peter Bakker

 

2015

- June
- July
- August
- September
- October
- Current

 

2014

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

 

More Archives

 

 

 

 

 

 

 


Copyright © 2015 by Ruth Malan
http://www.ruthmalan.com
Page Created:October 21, 2015
Last Modified: January 22, 2016