Software Architecture and Related Concerns

Architecture Training

Software Architecture Workshop

Enterprise Architecture Workshop

Role of the Architect Workshop

email icon.gif (1181 bytes)

Join our mailing list

PICTURE IT: The Art of Drawing People In

PICTURE IT: The Art of Drawing People In









Ruth Malan gave a presentation at the CAEAP Summit on June 20, 2009. The video of the presentation is on Vimeo: Picture IT: The Art of Drawing People In. [Just refresh the page if it gives you a "page not available" error.]

The purpose of the presentation was to draw attention to pictures (from rough sketches to formal models) as a medium for drawing people in--to get them engaged in the process of envisioning and collaboratively designing systems. Models and informal sketches are, too often, given short thrift--used, if at all, in a write-once kind of way to specify, rather than as an early vehicle to enhance collaboration and improve and test designs. The presentation isn't about the Visual Architecting Process (VAP) per se, but it is very much informed by the principles of VAP. The style of the presentation is designedly "retro," using hand-drawn images on paper to be consistent with the points being made in the presentation.

The right brain/left brain allusions are not intended to be taken as unquestioned and unquestionable fact but rather as a metaphor. This is a research frontier that is interesting and the intended take-away is that we need to allow that we use our detail-oriented, pragmatic, logical "left brain" functions much of the time. And while that "left brain" self is a bit suspicious of the "right brain" self (like it is wearing a tie-dyed t-shirt that is an adopted vestige of the 60's), there are times when we need to be creative, think big-picture and holistically, and be comfortable with ambiguity and uncertainty. Anyway, this picture helps us remind us that our understanding of the brain has come a long way, and has a long way to go. And that does nothing to undermine the point--our education system and our reward system helps to shape our experience, strengths and self concept, and we have to take courage and invest some of our cycles in the set of "functions" that have been associated (correctly, or not) with the "right brain." Walt Disney recognized this, and purportedly created separate physical spaces to play out the "dreamer," the "realist" and the "critic"--separating in space and time the "right" brain functions from the "left," to ensure that the right brain was not dominated into too early submission to practicality and logic. And, Disney, as Randy Pausch taught us, is a software engineer's hero!

This is what I said:

Sorry, we had no influence over the cover image... Also, if it gives you a "page not available" error, just refresh the page.

And this is what I intended to say:

PICTURE IT: The Art of Drawing People In

We all know the importance of visual representations. We wouldn't be enterprise architects without pictures like these! And yet... is there more?

Let's talk about the brain for a moment. In 1981 Roger Sperry was awarded the Nobel Prize for Medicine for his work on the brain, and in particular for his research on the specialization of the two sides of the brain. Jill Bolte Taylor's awesome TED talk ("a stroke of insight") has furthered popular interest in, and understanding of, the role each side of the brain plays. Both sides of the brain play a role in our thinking and perception; but they have different functions. More is understood about the brain thanks to Sperry and those who've followed, and a lot is still on and beyond the research frontier. But generally speaking, left brain functions are [were] believed to include analytic thought and logic, language and verbal processing, science and math [and "left brain" persists, at least as a handle for those areas of thinking]. While "right brain" functions include holistic thought, intuition, creativity, and art and music.

What do we notice? Our traditional education system focuses on highly developing "left brain" functions. Dan Roam, author of The Back of the Napkin, makes the point that if you ask preschoolers if they are good at drawing, the majority raise their hands; if you ask if they can read and write, only a few raise their hands. Then ask a class of 16 year olds the same question, and very few acknowledge they can draw, while most, if not all, can read and write.

Sir Ken Robinson makes similar points in his TED talk ("schools kill creativity"), and he tells a story of young girl. A teacher notices that this girl, who is normally somewhat disruptive, is quiet for once and the teacher, intrigued at this change in demeanor, asks the girl what she is drawing. The girl says "I'm drawing God" and the teacher says "But... nobody knows what God looks like" and the girl replies "They will in a minute."

That kind of confidence in our ability to envision and to move what is in our mind's eye onto paper gets lost. People like Sir Ken are making the case that it gets educated out of us.

Ok, it would make a certain kind of sense to say all this if I was talking to educators, but does it apply to us? Well, of course, next time you're in a meeting that isn't getting traction because no-one can envision what the system will look like, you can pick up a colored marker and start drawing, and tell them they'll "know in a minute"...

So, if we ask what pictures are good for, that's one piece of the answer. And it is the piece we typically rely most on. Telling the people who will build the system what it will look like. Specifying the solution. Explaining and defending the solution. Communicating our design. At least, so we hope.

Let's back up a moment and ask: What else are pictures good for?

First, pictures help us think. We form mental images. In our mind's eye, we see relationships--we see the whole in relation to its context, we see connections or spatial relationships, and we envisage interactions, sequence or temporal relationships.

Now, one might protest that it is all very well to talk about visual images in the context of architecture for buildings or physical products, but not software and messages and processes and capabilities, not the stuff we have to deal with as enterprise architects! We can envision things we see, but not things we don't see, right? Yet, some of our most brilliant physicists, including Einstein and Richard Feynman, were highly visual thinkers. Indeed, Albert Einstein said that he rarely thought in words at all; his visual and "muscular" images had to be translated "laboriously" into conventional verbal and mathematical terms and Richard Feynman, a brilliant theoretical physicist, enhanced the power of quantum mechanics by inventing "Feynman diagrams," a visual alternative to a formidable array of equations. (Eugene Ferguson, Engineering and the Mind's Eye, 1994). And we do have a standardized visual language for systems, the visual alternative to a formidable array of lines of code--thanks to visionaries like Grady Booch, Jim Rumbaugh and Ivar Jacobson, and others who played a role in creating the UML.  

So visual thinking heightens our ability to think, to discover, to explore and understand. Yes, pictures aren't just useful for specifying and communicating. And between the two, the mental images we form in our mind, and the pictures we use to transfer our designs to other minds, what role do pictures play?

Our minds are phenomenal. We can have all these thoughts, ideas, images tumbling around at once, but as we try to grab onto and tame them, how much we hold in conscious suspension at once is limited. When we draw these images out, we free our mind to add more. In Think Better, Tim Hurson makes the point that our ideas are like stale water that is sitting in the pipes, and we need to "run the tap" a while to get the ready-to-mind, old ideas out to make room for the fresh new ideas to flow. At any rate, by externalizing the images, drawing out our mental models, we can start to test them, throw challenges at them, improve them. Einstein, and actually Hans Christian Orsted before him, called these thought experiments, and by drawing our pictures we can trace and track and formulate ever more interesting, complex experiments. All cheaply--with sketches and thoughts. Visual thinking expands our mental capacity, and sketching these images and models expands our processing power still more. We create external memory, we can hold more information, and we can see, not just in our mind's eye, the relationships, the connections, the causalities.

So we draw pictures, models, to collaborate much more effectively with ourselves--with our moment ago, our yesterday, and our next month self. We use pictures to record our thinking, and to expand and enhance our own thinking. To test and challenge and improve our models.

And we use pictures to collaborate with others. Now, and over time and distance. By collaborating on pictures, we create a shared thought-space. Now we have more minds actively engaged in coming up with alternatives, testing and challenging and improving the models--while they are just sketches and the thought experiments and reasoned arguments are quick to play out and the biggest cost of change is the cost of letting go, the cost to egos. And the best way to keep egos from becoming cemented around ideas, is to keep the ideation process fluid. So early on, generating more and more ideas, alternatives, challenges keeps the team fleet of mind. Bringing in other minds, getting their input, their questions, their alternatives helps--they get drawn into the picture, and they help improve the picture.

So now we're getting to pictures that really help with communication. Not "immaculate communication" (Rechtin) of that miraculous one-way sort that we expect from people who draw a pay-check, but which we don't get--miracles being hard to buy, not even with a pay-check, not even in a recession. Communication that doesn't just produce "I see what you mean" but communication that draws people in. Collaboration produces buy-in and understanding, and the benefit of multiple experience sets and talents, and pictures are wonderful vehicles for collaboration.   

So we can use pictures for telling and selling. And we can use pictures even more effectively, for thinking and collaborating, for challenging and improving. For drawing people in.

Drawing people in. Drawing people? Up until now, if you've been nodding in agreement with me, you've probably been thinking of your experiences with topology diagrams, block diagrams, sequence diagrams, UML, sysML, BPMN, the good stuff of architectural thinking right? But drawing people in? Does that mean use case diagrams? Yes, all of the above. And more.

You see, pictures aren't just good for solving problems, they are good for defining problems. If you'll bear with one more Einstein reference--Einstein said that if he had 20 days to solve a problem, he would spend 19 days defining it. Over my years working in this field, I've come to realize that as much as we have challenges in solving problems, we have even greater challenges in defining them! Eberhart Rechtin said the biggest mistakes are made on the first day. Well, it may be the first 10 days, but the insight is that if we define the target wrong, if we set out in the wrong direction, no matter how well we do on the solution, we're going to have a hard time making a go of it. The first sets of choices constrain all other choices. They enable us to proceed. But they constrain what we can do from there on out.

So I said that pictures are good for defining problems too. Partly, I am just talking about using clouds (at least figuratively) instead of boxes to begin with. And stick figures. But I do mean more. Rich pictures of the system, for example. And stakeholder profiles or value models, context maps like competitive landscape maps, history maps and technology roadmaps and projections.

Buckminster Fuller made the profound point that a system--the whole--has properties that are not tell-able from the properties of the parts. If you study, for example, an apple, you cannot find out anything about gravity. It is only in the relationship of two bodies that you can find out something about gravity. It is the relationships among the parts, along with the parts, that are important in making a system what it is. 

Now you know the story of the blind men and the elephant, of course. But look what we have done--we have carved up the organizational elephant into independent parts, and even though people working on those parts are not wearing blind-folds (at least, they behave unquestioningly like they can see), they don't see the elephant. Well, not the whole elephant, but only out-of-context pieces and they make their decisions without the context of the whole. Enterprise architecture is about thinking about the whole elephant, and providing that context, that big-picture, to all of the parts.

Enterprise architecture is about designing the whole. The whole what? The whole enterprise? Well, that is a tall order. We do know that the approach of the last century, the approach that served the first age of expanding Industrialization--that is, the approach whereby enterprise design is treated as simply a matter of "divide and conquer," of specialization of parts, is not going to be good enough. Any company that figures out how to create synergies among the parts, is going to have an advantage over those that are uncoordinated "Frankenstein" conglomerations of ad hoc parts.

So the scope of our design problem is pretty staggering. The whole. The whole enterprise. Or at least, getting the scope right, defining the problem so that we start out in a high payoff direction, is vital when "the enterprise" is the system we're focusing architectural attention on. That's a high stakes game! How do we even begin to make progress on defining such a problem?

Yes, by drawing people in--with pictures. Getting the minds of stakeholders actively engaged in helping us map out the big picture. But not just the big picture. To envision the future. And the map to get there from here. By involving various stakeholders in this process, they see themselves, their ideas, their input, being integrated into the picture as it takes shape. We benefit from all the knowledge that is distributed in so, so many heads in this highly complex, highly specialized world of ours. We create a better picture, and a more powerful picture because we have drawn the people who are impacted into the picture.

Doing this, we draw people in. Ok, figuratively. But it helps if we do so literally too. Enterprise ecosystems are complex webs of social-, technical-, political-, economic- systems. But they are social first and last. They are made or broken by the social dynamics. People.    

Round about now, should we be returning to that picture of the brain? Holistic. Big Picture. Synergy. Harmony. Creativity. Approximations. Art. Right brain functions.

Drawing people in.

Not exactly what we trained for!

And yet we are ready. Unless we bear some unfortunate impairment, we don't use only one hand and we don't use only one side of our brain. To some extent it just takes a little courage. And we have that in good degree if we have audacity enough to think we can design enterprise anythings! 

As for drawing, it actually matters that our drawings aren't works of art. At least for our initial purposes. When we're starting out, getting a sense of the design problem at hand, and during early phases of solution design, we want to be fleet and fluid. Detail, precision, exquisite art at that point can be an encumbrance--that is, it hinders the process if it sends the message that what we're doing is more mature than it is, that change is a burden.  As our problem definition and solution design come into more crisp focus, once we've brainstormed and weighed alternatives and made tough choices, we may decide to elevate our vision and roadmap to the level of visual art, and add detail and precision to create design blueprints. But we'll make these decisions based on our communication needs.

The universal fundamental, though, is drawing people in. Getting input, defining the outcomes we want from the whole, designing the parts and their relationships so that we achieve those outcomes, and helping everyone who will build or configure the parts understand how they contribute to the outcomes of the whole.   

Creating the pictures that draw people in.

Source: script for PICTURE IT: The Art of Drawing People In, in Ruth Malan's architects architecting architecture journal.

Copyright 2009 by Bredemeyer Consulting
Author: Ruth Malan
Page Created: October 13, 2009
Last Modified: February 26, 2011