A Trace in the Sand
Online Architecture Journal
by Ruth Malan

I also write at:

- Resources for Architects

- Architecture Action Guide

- Trace In the Sand Blog

- Other Interests


Trace in the Sand
Architecture Journal

- Journal Map


- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- Current


- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December


- January

- February
- March

- April

- May

- June

- July

- August

- September

- October

- November
- December

- January
- February
- March
- April

- May
- June
- July
- October
- December


- February
- March
- April
- May
- June
- July
- August

- September
- October
- November

- December

- March

- April
- May
- June
- July
- August
- September

- October
- November
- December


- Girls and Computing

- Case Study in Invention

- From the Mind's Eye to Team Thoughtspace


- Problem Definition and Problem Solving

- Visualization Links

- Play Time

- Indy Air Show

- Getting Past Impossible

- Code as Modeling Language

- EA Doctrine

- EA Training

- Transitoriness

- Tribute to Meaning Makers

- Buckminster Fuller and Systems

- Gives One Pause

- Over and Out

- Kent Beck

- Architects of the Future

- Left Brain, Right Brain or a Toss Up?

- Picture It

- Left Brain, Right Brain as Metaphor

- Visualization

- CAEAP Talks

- Wasps and Visualization

- More Questions for the Geek Test




Chief Architects

- Charlie Alfred

- Rob Daigneau

- Don Ferguson

- Thomas Lee

- Brad Meyer

Chief Scientists

- Grady Booch

- Martin Fowler

Enterprise Architects

- Todd Biske

- Adrian Campbell

- Leo de Sousa

- Paul Homan

- James Hooper

- Nick Malik

- Jim Parnitzke

- Serge Thorn

- Tim Westbrock

Architects and Architecture

- Simon Brown

- Udi Dahan

- Louis Dietvorst

- Kevin Francis

- Sam Gentile

- Adrian Grigoriu

- Simon Guest

- Todd Hoff

- Alan Inglis

- Steve Jones

- Dave Linthicum

- Anna Liu

- Ruth Malan

- Chirag Mehta

- Gabriel Morgan

- Robert Morschel

- Dan Pritchett

- Chris Potts

- Arnon Rotem-Gal-Oz

- Shaji Sethu

- Leo Shuster

- Collin Smith

- Brian Sondergaard

- Michael Stahl

- Daniel Stroe

- Jack van Hoof

- Steve Vinoski

- Mike Walker

- Rodney Willis

Architect Professional Organizations



Agile and Lean

- Scott Ambler

- Elizabeth Keogh

Software Reuse

- Vijay Narayanan

Other Software Thought Leaders

- Jeff Atwood

- Scott Berkun

- Alistair Cockburn

- CapGeminini's CTOblog

- Joel Spolosky

CTOs and CIOs

- Rebecca Parsons

- Werner Vogels (Amazon)

CEOs (Tech)

- Jonathan Schwartz (Sun)

CEOs (Web 2.0)

- Don MacAskill (SmugMug)

Innovate/Tech Watch

- Barry Briggs

- BoingBoing

- Gizmodo

- Dion Hinchcliffe

- Oren Hurvitz

- Diego Rodriguez
- smoothspan

- The Tech Chronicles

- Wired's monkey_bites


Social Networking/Web 2.0+ Watch

- bokardo.com


Leadership Skills

- Presentation Zen


Strategy, BI and Competitive Intelligence

- Freakonomics blog

- Tom Hawes

- Malcom Ryder


Um... and these
- Nick Carr

- Tom Peters


Green Thinking

- Sylvia Earle, TED

- CNN Money Business of Green videos

- Matter Network




June 2009

6/2/09 Your Co-ordinates

This journal contains notes I take as I explore software and systems architecting and architecture, and what it takes to be a great architect.

6/2/09 Girls and Computing

Some time ago, I surmised that more girls would become interested in software careers if the role of software in doing good was messaged more effectively. A preliminary report from an ACM-WGBH study apparently bears this out:

"Computing empowers you to do good. With computing, you will be able to connect technology to your community and make a world of difference—reducing energy consumption, improving health care, enhancing security, reducing pollution, and advancing learning and education. Rated highest with girls and Hispanics." -- ACM-WGBH Report Finds Large Gender Gap in Teen Ratings of Computing as a Career June 2, 2009

Of course, the problem is not just one of diversity:

"a UCLA study ... found the number of undergraduates choosing a computer science major was down 70% from 2000–2007"


"In another study, 80% of college freshmen said they had no idea what computer science majors actually do."


We have a perception problem. Software, and its development, is hidden. Even companies that compete largely on their software prowess, like financial institutions or manufacturers of products with embedded software, don't generally recognize the role software plays in their business. But who'd think that software plays a key role in malaria research in Africa, or micro-finance, and on and on? When I got into computer science, it was because the (mechanical) engineers I hung out were into programming. Things are a lot different now, and many of the kids who think computers are cool got into programming because of computer games. That just seems an odd kind of social to many girls. Our tack seems to be to make game programming more girl friendly (like Storytelling Alice) and that's a start. But why not make the role of software in doing social good more visible--too?

6/26/09: Or, how about games that do social good? See "Beating the Bullies--changing real-world behavior through virtual experience."

6/2/09 Case Study in Invention

Last night we watched The Dam Busters. Yes, the black and white WWII movie. Well, it is a war movie, and it is about creating a bomb that killed many people and animals, so I have qualms noting this: it is a good case study of the invention/innovation process. Talk about the "political career of a prototype" (the name of a chapter in Henderson's On Line, On Paper book)!

Well, if you know of other movies that showcase the innovation process, please do let me know about them!

6/2/09-6/5/09 Engineering: from the Mind's Eye to the Team's Shared Thought-Space

For those who think that software, being intangible, doesn't lend itself to visualization the way a physical system like a bicycle or pump does, this is worth pondering:

'Historians of science in the late twentieth century have documented the persistent use of imagery by Ludwig Boltzmann, Albert Einstein, Niels Bohr, Werner Heisenberg, and others as they developed modern physics. 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.

In the late 1940s 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. Feynman thought that Einstein, in his old age, failed to develop his "unified theory" because he stopped thinking in concrete physical images and became a manipulator of equations.'

-- Eugene Ferguson, Engineering and the Mind's Eye, 1994

We have our modeling language, thanks to Grady Booch and other early champions of a visual language for software, as well as the many people who have poured hours and hours (even days, weeks, and years) into the next generations of the UML, and now SysML, standards.

Part of what modeling does, is externalize the mental models we architects and engineers hold, so they can be shared and thought about and (inter)acted upon. Our minds are amazing. Yet what we hold in our mind's eye is of limited value--we see this as soon as we draw out the models we have in mind. If we accept fallibility and work at finding alternatives and exposing weaknesses, we quickly find that our first idea stands to be improved upon. This is even more powerful when we involve a small team in the creation of models, "stress testing" them with questions (why? how? when? where? what do you mean?) and scenarios (what if?) and a discipline of seeking alternatives (what else?). Moreover, once we have created this externalized thought-space, these sketches and models, we can bring others in to help test and improve our thinking still more. Some stakeholders will help with how we have defined the problem, and others with our attempts to address it most pragmatically. And the discipline of sharing and explaining the models and thinking will help drive us to seek and find better and better ways to do this through simplification, abstraction, and rendering.

Of course, I also mulled this topic in: 2006: Architects and Models, and Interplay between Requirements and Architecture; 2007: Why Bother with Models; 2008: Origami and the UML...

6/2/09-6/5/09 The YAGNI vs. BDUF Battle for Mindshare

While the Agile Manifesto has done an enormous amount of good, it has been (ab)used to banish modeling under the mantle of valuing code above all else. Well, yes, working software. And yes, to get to working code, just enough design really helps. Yes, models. But unfortunately in our drive to simplify, to reduce our world to binaries, the options got reduced to: code good; BDUF bad. And no shades in between. Not universally. But often enough to set a wave of anti-BDUF reverberating through the industry, making it a lot harder for champions of JEDUF to get traction.

Under YAGNI, we don't build code to check our design against, for example, growth scenarios (in the scale sense and in the market segmentation sense). But when we are evaluating models we can, though we need to stay fleet--modeling just enough. Of course we will still encounter surprises in building the system, but any surprises we uncover early with quick and dirty sketches and quick cycles through different facets of the system concept and architectural design are surprises we address before the design is cast in code. Malleable as code is, as the code size grows, inertia sets in--worse when the structure is allowed to degenerate, and entropy sets in. On a quick scan, I don't see a measure of entropy for software development, but I suspect it is something like the measure of developer hours not available for producing (new) value (because they are being spent on bug fixing, code understanding, remembering and reinterpreting, refactoring and simplification, etc.).         

Now generalizing across the software field (always dangerous), we do tend to fall into something of a zeal trap--we embraced modeling and round-trip engineering so whole-heartedly we burnt ourselves out on them and created industry anti-bodies to the BDUF-bogey. Swinging the other way, with battle cries of YAGNI, much of the gains we'd made in creating a visual culture among software architects and engineers was undercut. This is not to say that design necessarily was thrown out with the proverbial bath water. Indeed, refactoring came into vogue as an evolutionary design approach that works in the medium of code. This is good, naturally. But it requires discipline not only on the part of developers, but the management team--and discipline, especially when responsibility for it is distributed, is hard to maintain under pressure. The need for architectural redesign may also be harder to catch early on (especially if there is no architect responsible for system integrity and watching for erosion of structural integrity), and require a big schedule hit late in the project. Tools like Lattix help visualize the code structure, making dependencies visible, and this is another big contribution to evolutionary design. But these approaches are reactive, rather than proactive (yes, yes, in terms of moving forward they are proactive, but they are first reactive--responding to a problem, but avoiding escalation of the problem). This is important, but using a sensible amount of proactive, intentional design has big payoffs too.

Here's an unusual article in the age of anti-BDUF: They Write the Right Stuff, Charles Fishman, FastCompany.com. These are excerpts from the article:

"The B-2 bomber wouldn't fly on its maiden flight -- but it was just a software problem. The new Denver airport was months late opening and millions of dollars over budget because its baggage handling system didn't work right -- but it was just a software problem. This spring, the European Space Agency's new Ariane 5 rocket blew up on its maiden launch because of a little software problem. The federal government's major agencies - from the IRS to the National Weather Service -- are beset with projects that are years late and hundreds of millions of dollars over budget, often because of simple software problems. Software is getting more and more common and more and more important, but it doesn't seem to be getting more and more reliable."


"And that's the point: the shuttle process is so extreme, the drive for perfection is so focused, that it reveals what's required to achieve relentless execution. The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering."

I don't know if it is standard practice but it is prevalent--there tends to be more awareness of the cost of design flaws when a small change in a mold can incur machining costs into the millions and delays in production start-up. Because these costs are more visible, the design process is more rigorous. Likewise in the case of the space shuttle. Few of our development efforts have the kind of visibility that the shuttle program has. Many have a high price tag, but generally not $35 million. (And then there's the likes of Vista, estimated to have cost Microsoft $10 billion!) Still, somewhere between no design upfront and no code until the design is complete, and barely money for coffee and pizza to a $35 million price tag, there are a lot of shades--of green and red.    

Refactoring is a great design tool. We use it in visual architecting! Iteration and stakeholder participation to discover, improve and validate "requirements" (interpretations of what the system needs to do and be) are great design activities too. We use them in visual architecting! Dependency analysis is a great design tool... etc.

Ok, so architects generally know all this. But architects are under pressure from the mainstreaming-Agile wave. When "architect" is a hat everyone on the team wears, architecture is easily compromised under schedule pressure and uneven system design experience, including uneven predilection for system thinking and lack of tolerance for the social/political aspects of defending architectural integrity. And schedule pressure is an important project tool too! It makes us get things done. The architect as guardian of system integrity and the project manager as defender of the schedule play important counterbalancing roles. Each is dependent for success on the other, they must work well as a team, and they are responsible for advocating the position of their respective charters. The architect ensures structural integrity that will see the system more predictably to its first release, and then subsequent releases.  

6/4/09: Some great kludge photos!

6/4/09 Tentative Entry into Flikr'ing

Inspired by Dave Gray of Communication Nation (his visual thinking collection is here), I trepidatiously put one of my kludge sketches on Flikr.

                         Architect Addresses The Kludge by TraceInTheSand

I just like the face in the kludge; it was pure serendipity--of course, you could say subconscious genius, but I couldn't. Not in public. Oh, I'm kidding! Goodness, you have to remember that self-directed satire thing I have going!

Uh... I'll have to think carefully about whether to put more of my sketches/cartoons on Flikr... 

6/4/09 Problem Definition and Problem Solving

"Lehrer provides a number of real-life examples of how these feelings inform the most subtle of decisions without us being aware of them. A Navy officer is able to quickly know whether a radar blip represents a rapidly approaching Navy jet returning from a mission or an incoming Iraqi missile. Tom Brady, the second-string New England Patriot quarterback, makes a series of miraculous on-field plays to guide the Patriots to a 2002 Super Bowl upset. Other detailed examples include learning how to be a first-class backgammon player and a World Series of Poker champion.

By interviewing each of the men, Lehrer discovered that what might look like good split-second hunches arose out of detailed prior analysis of each man's steps to decision making. Each was a student of his own mind, including making detailed accounts of where prior decisions had gone wrong."

'How We Decide,' by Jonah Lehrer, by Robert Burton, SFGate, Sunday, February 15, 2009

This "re-mark" from Dan Moyer (on Dave Gray's "unbook" Marks and Meaning) conveys volumes about the power of pictures! 

6/5/09 More Visualization Links

6/6/09: Play Time

We spent the afternoon kayaking on Lake Monroe. It is so magnificent to be out on the water, and with temperatures in the high 70's it was just perfect. 

Hobie kayaking on Lake Monroe (6/5/09)







We saw a bald eagle, and a number of great blue heron. Alas, I only had Sara's (pocket-sized) camera... the Hobie kayaks are way stable, but it can get splashy in the wind so I haven't ventured out with anything more substantive.

6/7/09: Indy Air Show

We took our resident airplane buff to the Indy Air Show. We had fun--how often does a boy get to put his arm around his dream older Lady (a P51!), got way too much sun, and wondered how much longer humanity can support these air shows... It is a tricky thing, raising funds to support Indiana's children's charities while burning fossil fuels and contributing to global warming. What times we live in--where our consciousness is being raised (too late?) and conscience becomes a plague when we do the things we used to love doing!

We've been busy, and look set to continue to be, but we decided that what with having to replace our roof, and the economic uncertainty, we ought not to travel this summer. So, we're discovering how much southern Indiana has to offer over the summer! Sara has tennis, swimming, writing, acting, ballet and GIMP/Python camps, and Ryan has fishing, swimming, sailing, adventure, and GIMP/Python camps, so the family "taxi service" is in full operation! Add to that building the great American entrepreneurial foundation--yes, lemonade stands... It serves as a reminder that kindness is alive an well in suburban America when people stop what they're doing to patronize that day's "lemonade and pastries" stand.      

6/8/09: Getting Past ...Impossible!

Tom Hawes posted a great article on his Competitive Intelligence blog. It is a wonderful post in a number of ways, not least of which are the use of a potent personal story and the important lesson he extracted from the experience:

"No, the damage he nearly did to me was that he implied in authoritative tones (as only a doctor can) that the surgery was impossible. No one could possibly do what he could not do. It was impossible."  -- Tom Hawes, "Getting Past Impossible", June 4, 2009

Now go on over to Tom's blog for his life lesson! He frames it in terms of CI, but it very applicable to product and systems development. It reminds me: there is strength to the argument that the most profound lessons are learned from experience, but the lesson is much less costly when it is from someone else's experience!

6/9/09: Code as Modeling Language

For counterpoint to using visual modeling languages, I highly recommend A Conversation with Arthur Whitney. I started out programming embedded systems in assembly language and Forth--which was a great medium for creating one's own DSL home-brew. Well, in the hands of a talented language designer and sharp programmer it was powerful. But... it was the sort of environment that quickly sorts the average from the talented. Is this true for K and Q? Certainly AW is a man apart--

AW ... I never comment anything because I'm always trying to make it so the code itself is the comment.

BC Do you ever look at your own code and think, "What the hell was I doing here?"

AW No, I guess I don't.

Enough said, right?

Elegantly simple, beautiful code for complex tasks takes smarts, but it also takes discipline:

BC When you're actually in the practice of writing code, do you try many drafts?

AW I've found the best thing is just to get something running, and then I'll redo it probably 10 or 20 times until I can't get it any smaller.

BC Do you redo it for aesthetics?

AW Yes. What I tell my community is if you can find a shorter, more elegant program that isn't much slower than my code, I want to hear about it. And if it's shorter and faster, I absolutely want to hear about it.

BC Although I don't know that I've got the same discipline, I share your sense of aesthetics about beautiful code. I don't see that sense of aesthetics being very widespread in software. Shouldn't it be, though?

AW I think so. The thing about beautiful code is, first of all, it's beautiful. Second, it's a lot easier to maintain.

Then... AW all but used the impossible word...

BC What's the solution?

AW I think we just won't be able to do those kinds of algorithms.

I liked AW's poetry analogy. Bryan Cantrill (BC) responded "Poetry captures the aesthetics, but not the precision."  There's sloppy code and sloppy poetry, but tight poetry has interesting properties, precision among them, in common with tight code. Sure, they're not the same--but then, it's an analogy not an identity.

Poetry is very precise, and poetry, like code, relies very much on the "spin-drier mind" that produces breathe-taking surprises with the astonishing fit that seems to come from nowhere, because it comes as if by magic, from the inner, mostly hidden, working of the mind. The mind. The great integrator. 

A Comment on Comments

If we comment code to say in common language what the code says in the programming language, we're being redundant--and we should have a good reason to be redundant (for example, redundancy is ok if it lets you reference a post that would otherwise be covered in layers and layers of traces in this sand...). If we comment code to (succinctly) record why we made a decision we made (referencing a requirement, a design pattern, a judgment call, etc.), and what the alternatives were, we are doing something that is not otherwise contained anywhere in the code. Then we have a choice--record that rationale in the design document, or record it in the code. If we maintain a design document, great! If not, the code is the repository for (all) the design thinking. 

A Comment on Visual Design Language

In case anyone is concluding that what's good for AW is good enough for them, allow me to insert a quick reminder. Visual design languages give us a way to visualize the system, architecturally significant mechanisms, etc. That is, we can see the bigger structures and relationships among them; we can see the system fit-to-context; etc. The code, the sheer mass of it, masks these relationships. Yes, those who know the code well, hold this structure in their mind's eye, but unless they have a means to explain and defend it, the structure is vulnerable to erosion by all those who work on it. Moreover, models enable us to think about the system dynamics, thinking through aspects of the system behavior and the impact of structural choices on system behavior. As smart as we are, we have a slate of tools to help us create better designs. Code, trial-and-error, simplification and refactoring, behavioral and structural analysis tools, all these are part of our toolkit. And careful separation of concerns and analysis with the help of models is a thinking tool too--enabling us to improve, test, question, refactor, simplify our designs even while they are in sketchy model form. Moreover, it is a very critical collaboration tool. It helps us get our good ideas on the table (or the walls), so that we can share ideas with others on our team, and still others as we review and test our models on a regular improvement/validation rhythm.

6/12/09 If you assumed that my "redundant" link on comments wasn't worth a stop, you likely missed this:

"The trouble is, the code doesn't explain why; the processor doesn't need to know why. (That is what distinguishes a computer from a two year old!) " -- moi, 8/9/08

Ok, that was for fun, but what about this for creating a yardstick (the kind we measure ourselves by, and threaten to beat ourselves with) for why, what and how to document:

"How do we make these decisions? How do we propagate these decisions? And how do we evolve these decisions?"

-- moi, 8/9/08

Which leads into broader social questions like "Who cares?", 'What do they care about?" and "How do we influence them?"...  and how do we keep ourselves open to their influence, including being open to the notion that they have good ideas!

6/10/09: Enterprise Architecture Doctrine and a Template for Values

The EA Doctrine has gone out for review. If you're interested, you can get access to it by joining the CAEAP Group on LinkedIn (assuming you're already a member of CAEAP, that is). It was interesting being part of that--most of us were working together for the first time, and have never met face-to-face. It is striking what can be done in that context, with goodwill and willingness to serve as the common foundation. Mark Lane remarked "And yes, some of us are still talking to each other ;--)"  Um, is he referring to me? I was pushing hard at the end to keep working the revision process to simplify and trim, and I don't know if I annoyed people who were already well out of bandwidth/energy--and patience with a perky but gently-pushy pink person... Several of us stuck with it, and even yesterday good stuff was being done to hone the document. I would love another week on the Values and Principles, but the team would definitely not talk to me if I mentioned that... :-) I just did? Don't worry, they're too busy catching up on their day jobs to read this.

Just so this idea doesn't get lost, though--I got inspired and only today (inspiration has it's own timing) suggested that we revise the value statements so that they fall into the following pattern:

valueName -- to statement of the value. Living this value, we: list of behaviors

For example:

  • Harmonious - to achieve cooperative alignment among stakeholders.  Living this value, we:
    • Facilitate convergence
    • Strive for consistency in practice
    • Foster collaboration and goodwill
    • ...
  • Evolutionary - to respond to change adaptively and flexibility.  Living this value, we:
    • Promote ongoing reflective learning
    • Proactively scan for environmental changes, opportunities and threats
    • Investigate options to address challenges
    • Provide creative alternatives

-- adapted from two of the CAEAP EA Doctrine value statements

Once the values are put so crisply, you have to really focus and tune, edging towards greater precision and making the statements more actionable as a result. Well, even if the Doctrine team doesn't like, or doesn't have the cycles left to embrace, this format, I think it is a good one! So, put it in your toolbox and pull it out when next you're starting up a team. Remember, values are a key element of identity, and if you want a cohesive team, the cycles you spend with the team creating a shared team identity (mission, values, team principles, vision, ...) will have huge payback. (If you're skeptical, just look at the impact of the values and principles in the Agile Manifesto on the software community.)

6/10/09: Enterprise Architecture Workshop Scheduled

Times are tough, so we are really going to rely on you to help spread the word--Dana Bredemeyer will be teaching the next EA open enrollment workshop on August 31-Sept 3, in Chicago (which won the vote over Boston by 6:2). I guess the Chicago folk were just more proactive, but that's democracy for you. The early enrollment discount deadline is June 29th. A Trace in the Sand

6/10/09 Transitoriness

Ok, since no-one has mentioned it... isn't "A Trace in the Sand" --read silicon--a great name for this digital journal? There are not many areas where I have the lead on our good Mr. Booch, but in reflecting on the wash of time on the impact of our work, I guess I did! Grin. Yes, I'm referring to his quote in his June 8 blog post versus the name of my journal and blog.

6/10/09 Ardmore--A Tribute to the Meaning Makers

Ardmore ceramics are being displayed at South Africa House in London, June 9-12, and if you act quickly you might be able to get a piece from the show online (the most expensive are listed first) or from Ardmore's gallery online (functional art and masterpieces). It is worth looking at the masterpieces--each artist is amazingly talented, but the pieces are the product of teamwork between a sculptor and a painter, and it is neat to see that synergy in art. The combination of African animals--some with a mythical twist, flowers, the startling color and intricate painting, make for very unique pieces. I confess, the art and style has grown on us, so if at first you don't get the appeal ... uh... don't go back!! It's addictive and expensive--one of the Ardmore artists told us there is a lady in North Carolina who has into the hundreds of Ardmore pieces in her home! I suppose there are still a few people who can spend $6,000.00 on a pair of chicken candlesticks (VIR51), and if that's their thing, I'm sure they could scratch the world over and never find a finer pair! Anyway, these are artists who are worth a moment of your time and mine to honor them. They have surmounted incredibly tough childhoods with impoverished backgrounds and emerged creative, talented meaning makers--artists who deserve awe-struck admiration. 

Looking back through February's entries to find the one on Ardmore, I was reminded that Dana spent a weekend there in Feb--it is about halfway between Johannesburg and Durban, and he split the distance with my Mom and brother and his family (I was quite envious writing that entry... could you tell?). Anyway, I realize that... if you're tired of my single-minded focus on visualization and modeling these days, perhaps you could jump back to February's entries. I bull-dogged the need for optimism a little zealously, and went off a bit on the long-tail phenomenon, but otherwise it was a reasonably varied month... 

6/10/09 Buckminster Fuller and Systems

Dana searched out the 40 odd hours of video of Bucky Fuller doing his "core dump" at age 80, and has been relaying some of the Bucky wisdom. (Dana first watched this series as an undergrad, the Summer after Bucky recorded them.)  Ok, I'm so not going to do justice to Dana's telling, or Bucky's wisdom, but I'll relay what I made of it...

Bucky makes the point that a system--the whole--has properties that are not tell-able from the properties of the parts. That is, if you consider the parts as parts, you couldn't predict from the parts the properties of the system assembled from those parts. (Whereas if you consider the whole, and some of the parts, you can predict the properties of the remaining 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.  

This speaks to the importance of intentional design. For a long time, we assumed that specialization (the parts) would take care of itself, but the whole has emergent--not a priori predictable--properties.  It is all very well so long as all competitors compete on the basis of ad hoc conglomerations of parts. As soon as one or a few figure out more intentional system design, that puts pressure on the "divide and conquer" pack.

I'm not sold on the notion of cosmic fish, although they smack of Elizabeth Gilbert's genie... My entry into the greater world of thought was in the age of contraction and reaction to the expansion and open-mindedness of the 60's and 70's, and it has left a (somewhat) conservative imprint on me.

6/11/09 Gives One Pause!

Anyone who cares about the health of our industry, may want to take a look at this ComputerWorld article. Here's an excerpt:   

"...The most important antigen is the machismo that continues to permeate these work environments. We found that 63% of women in science, engineering and technology have experienced sexual harassment. That's a really high figure.

They talk about demeaning and condescending attitudes, lots of off-color jokes, sexual innuendo, arrogance; colleagues, particularly in the tech culture, who genuinely think women don't have what it takes -- who see them as genetically inferior. It's hard to take as a steady stream. It's predatory and demeaning. It's distressing to find this kind of data in 2008."

In response to Martin Fowler's piece "Smut on Rails," I wrote an entry last month, then pulled the entry... It is the classic kind of self-censoring women do on this subject! Partly, I thought that it's rough on those who have some awareness of the problem, to have the issue raked over again and again just because we have a segment of our population that is arrogant, but not just arrogant--arrogant and demeaning along gender lines. And partly I thought that the people who need to understand the message, just aren't receptive to it. There's a certain amount of "it's 2009; get over it already" out there, and rather than court hostility we hush up. Abrasive hostility, after all, is a good part of the issue we're talking about! When I began programming, the field was much closer to a 50-50 split, but there has been tremendous attrition and young women are less interested in computer science/software development careers now. It is very interesting to see the research evidence mounting. One incident you gloss over. Two. Several... it's starts to wear on a person. We tell ourselves it doesn't matter; there are so many wonderful people and so much good, exciting work in this field, we'll just overlook it. But the insidious erosion of our sense of self builds, and we leave the field. I never realized that the numbers were that high:

"More than half of the women in science, engineering and IT leave the field at mid­career."

--Kathlyn Melymuka, Why Women Quit Technology Careers, ComputerWorld, June 16, 2008

6/13/09: You know the adage "likes attract" ... and yet stable chemical compounds are made of elements that have an affinity, but are not all the same. This seems to be true for productive, innovative teams too. What's more, the same abrasive, arrogant types who repel women with their superiority complex, can also make the development context inhospitable to many men. It does appear, though, that women, who are often the gentle nurturers of team/community, are being repelled from our field, and that is very unfortunate.  

6/11/09 Over and Out!

Martin Fowler wrote a post celebrating the values statements in the Agile Manifesto. I admire the Agile Manifesto and what it has achieved in the software field. Where** it has bred antigens to good discipline and habits in our field, it is more a problem with our binary all-or-nothing biases than the Manifesto itself. But given our propensity to say "preferring X over Y means NO to Y," rather than preferring X over Y means "in a toss up, go with X," or "more X than Y," or "use Y judiciously," or something like that, the format is somewhat dangerous. For example, does "Responding to change over following a plan" mean "NO plan"? If change is the only reliable constant, and we'll always respond to the changes, NO plan makes sense. Right? Hmm. One has to allow for context. I value flexibility over intractability so strongly I'd be tempted to say absolutely. So much so, that on the question of whether to be flexible or intractable, I have to confess I am intractable about my preference for being flexible.     Lake Monroe

"The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function. One should, for example, be able to see that things are hopeless yet be determined to make them otherwise." F. Scott Fitzgerald quoted in the opening chapter of The Opposable Mind

I wonder, should The Opposable Mind be required reading in software? At any rate, it is good to remind ourselves to stop looking at polarities and look for the integrative solution.

** Of course, if you've been following along with my journaling, you'll recognize that I distinguish between true agile projects and projects that use agile as a nom de guerre to excuse bad practices that appear agile (because they are getting "working" code out), but which become increasing inert under the load of technical debt. That, of course, is the great paradox of agile.

6/13/09 Just Playing on the Lake

We whiled away a good part of this year's national "Get Outdoors Day" exploring another "finger" of Lake Monroe (in the Charles C. Deam Wilderness).

6/14/09 A Visual History of Visual Languages?

Reading Eugene Ferguson's exploration of the history and role of drawings (from sketches to models rendered in formalized visual languages) in Engineering and the Mind's Eye, I was thinking that it'd be fun to do a graphic history of visual language in software. I expect it would be the kind of thing that the Computer History Museum should have on display, because our ability to create more and more complex systems has a strong dependence on our ability to use visual representations. Yes, patterns too--but we rely on visual representations to convey many of our design patterns.



6/16/09 Kent Beck: Just You Wait

This evening I watched Kent Beck's QCon/InfoQ talk about trends and where they're going. Kent used an interesting strategy to think about trends--namely to draw on where things have been and where we can see them going, out until you just can't say for sure what will happen next, and then think about that. Here are some of the points Kent made (as paraphrased by me) that I found interesting:


  • more frequent releases: the trend has been going down, from releasing every 3 years, to 6 months, ... As you draw that out, you see that daily, and more frequent, releases will become more common. Today we don't have the release, testing, programming, social relationships, trust of customers, etc., setup necessary to do that. Still, pioneers are out there doing that today, and the trend is headed that way. And it drives so much development behavior. What will it all mean? For one thing, it will squeeze out all of the rationalization and minimization we rely on...

New Approaches:

  • Design: when you look the likes of Amazon and Google, with the scale of computing that they have going, you see that they are doing a beautiful job of design--the layers are clear, the separation of concerns is there... And you see that where things are going, design will become a more and more important skill. If you take a goal like frequent releases, the prerequisite comes back to design. We went through a period where we could get away with crummy designs, but more and more good design will be important, and good designers will be in demand.

  • Tests: as release frequency goes up, you just don't have the time to wait for someone else to catch your mistakes, so we have to catch mistakes early.

Why? Money can't be the only goal, because that ends up causing problems you never thought about.

(from my notes taken listening to) Kent Beck, "Just You Wait," San Francisco QCon June 12, 2009, posted on InfoQ

You've just got to love serendipity. I've been going on and on about design (and the visualization of design) this month, and along comes Kent and he's saying (I'm putting words in his mouth--but he's at least almost saying) we took a bit of a detour (crummy designs) but we have to get back on the path to good designs to do the things we're trending towards--quicker releases, etc. And he didn't say this, but it's the obvious extrapolation--we need to get better at not just finding errors sooner, but not inserting them. That is, we need to get better at design. Better at integrating proven principles and design fragments (mechanisms and patterns for mechanism design) as well as better as exposing weaknesses in our designs before they are fully built out.

6/16/09 Architect's of the Future

I was debriefing Dana on Kent's technique for trend-gazing, and realized that a point I do make, needs to be made more forcefully. First, some background.

If you've read our "Software Architecture: Central Concerns, Key Decisions" paper or taken our workshop, you know that we talk about architecture in terms of scope (of decision responsibility and perspective/visibility) of the system under design (evolution). That is to say, a distinctive characteristic of architectural decisions is that they need to be made from a broad-scoped or system perspective, to address system goals and cross-cutting concerns. Any decision that could be made from a more narrowly-scoped, local perspective without compromising system goals, is not architectural (at the current level of system scope). This allows us to distinguish between detailed design and implementation decisions on the one hand, and architectural decisions on the other—the former have local impact, and the latter have systemic impact. That is, architectural decisions impact, if not all of the system, at least different parts of the system, and a broad-scoped perspective is required to take this impact into account, and to make the necessary trade-offs across the system. Or, in Bucky Fuller terms, architectural decisions are those where we need to think about the whole, and properties of the whole that arises from the relationships among the parts, not just the parts (in isolation).

We also talk about business alignment and the factors and forces impinging on architectural decisions:

And then we add the time dimension:

I've also been making the point that architecture/technology roadmaps are key deliverable for architects--read: creating and maintaining a technology roadmap should be a bullet point on your list of responsibilities; you should create a culture where you and your colleagues watch for broadly relevant technology, vendor or competitor announcements, trend projections, etc. and informally jot these on the roadmap; it should be on your quarterly*** to-do list to formally update the roadmap, make projections and assess implications (risks and opportunities); your roadmaps and the contribution you make as a result should be on your performance review; and this responsibility should be on architect job posts.

Typing these all together: it struck me that it is worth saying explicitly that if we didn't have to think about the future, we wouldn't have to worry about architecture! It is only because we have to be sure the structure will stand up to the stresses and strains of the future that we have to design and defend (explain, protect, nurture, sustain and evolve) the architecture. Yes, what we're about is accommodating and enabling the system to flourish despite the stresses and strains of the future--in a month's time when code from 30 developers distributed around the world is going into the daily build, or in 6 month's time when we release and users start to fit the system into their lives (or fit their lives around the system...), or 3 months after that when we release the first derivative. The future--when, if we did our job right and created a user experience that delights, the scale of use grows, and grows; and the scope of use grows, and grows. The architect has to draw a very delicate line between pragmatism and simplicity and readying the architecture for tomorrow, and tomorrow's tomorrow. Yes, you have to make judgment calls. Lots of judgment calls--that life of the architect that is, as Kruchten put it:

"a long and rapid succession of suboptimal design decisions taken partly in the dark."

Philippe Kruchten, "The Architects -- The Software Architecture Team," Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1). Kluwer Academic Publishing 1999.

*** Ok, I threw "quarterly" in there to challenge you. Obviously you and your team will pick the rhythm, but only updating the roadmap at the clip that the strategy gets updated (annually) is too slow--you'll be blind-sided, and I don't want to be hauled over the coals when you are! Besides, Dana makes the point that you get good at something through practice, and it takes some practice to hone that prefrontal cortex function so that one becomes better at sifting possibility for architecturally significant opportunity and threat. If you keep a rolling horizon of history, announcements and trends, and projections, that is updated at reasonable intervals the overhead is not very big, but the gain from becoming better at interpreting what is happening and spotting where things are going can be huge--make or break kind of huge.

I am specifically not saying that you need to build features and mechanisms for every possible eventuality! The Minimalist Architecture Principle predated the Agile Manifesto and all things YAGNI (though the paper that made the principle "famous" was published in September 2002)! We'd be insane if we thought we could future-proof our systems! But if architects--product, system, domain, portfolio and product family, chief and enterprise architects--aren't watching the technology frontier, and staying aware of what is happening in the markets of relevance, reaction/adaptation time will be slower. Also, if we don't think about change cases, abUse case, growth scenarios, and so forth, we won't challenge ourselves to think about how our architecture will be stressed. If we invoke YAGNI and spend no cycles thinking about these likely, as well as unlikely but very damaging, points of stress, our architecture will be the child of our first set of unchallenged ideas. We want to keep it simple, and Occam's razor is a useful start. But just like we need to let our children be challenged so they learn how to adapt and respond to challenge, we need to throw anticipated and possible significant challenges at our architecture in the form of thought experiments--and from there we may even decide to prototype some aspect of our design to get a measured sense of whether our approach will do. (Charlie Alfred helped push my thinking along these lines back in September.)

6/17/09 Left Brain, Right Brain or a Toss Up?

I stumbled on a neat "test" (mild artistic nudity in the silhouette) of right brain/left brain function. Actually, I have no idea how good it is at determining one's right versus left brain proclivities (that's code for: I'm skeptical), but as optical illusions go it is cool! I can make the dancer swing from side to side, go clockwise, or anti-clockwise, all at my command. The astounding thing is that I'll be seeing her swinging side to side, and Dana will be seeing her spinning clockwise -- we're seeing the same screen at the same time, but we're each seeing the dancer move differently. (I tried this with all four of us, and the kids could also make the dancer switch directions pretty much at will. So far, Dana only sees her spin clockwise.) This is a great illustration of how brains can receive the same stimulus and produce different perceptions!

6/18/09 PICTURE IT: The Art of Drawing People In

Warning: What follows is my "brain dump" for my talk on Saturday. If you'll be at the CAEAP event, do not read this! It will be bad enough hearing it then, without already having previewed it.... For the rest of you: no cold water please! I'm self-critical enough that I can create a crisis of confidence without anyone telling me they "don't hear the music" or "see the art"... On the other hand, feel free to praise profusely, even if you have to compromise your integrity, to build my self-esteem. I'm kidding! But I am going to need all the confidence I can muster. Mark Lane asked me to present (a moment of weakness, I'm sure), and I had this flash of inspiration for a topic, and in the rush of that moment, I agreed... Silly me! Grin. Oh yes, I plan to draw "live" (but I have a trick up my sleeve). So you won't see the art--until Saturday, that is. Uh, I have been researching and mulling this for weeks, as you all know. Nothing that follows should be new to you, except for the integration. Ok, (deep breath) the first draft of my script follows: 

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 believed to include analytic thought and logic, language and verbal processing, science and math. And 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.


Yes, there's more I could/should say--but 20 minutes necessitates a fierce cull on all the things one would like to say! And no doubt there's plenty you think I shouldn't say... 

Sigh. Well, I have a day to scrub and polish. Rewrite. Panic. Freeze. Crumple. And decide never, ever to be such a fool again... Can anybody tell me why I'm doing this? I'm shy, remember?

UGH!  It's Sunday already, right?

Well, that was cathartic. Thanks for bearing with me. 

6/19/09: Uh, right; encouraging silence. You helped a lot! Grin.

6/21/09 Yes, it's Sunday!

This tweet-like stream reminds me--I thought of introducing my talk thus:

So everyone (that matters) is sending out tweets these days even at CAEAP, and while that thought terrified me at first, I began to realize it was a good thing. You see, I got ahead of everyone who is just tweeting about the current moment--I put my talk online two days ahead; people would know what I was going to say in the future. How cool (or "kuu" according to Kent Beck) is that? Ok, I was hoping for some community feedback--positive of course.  But I realize there's another benefit: if my brain freezes in terror, someone out there can tweet in and give me a blow-by-blow of what I'm about to say next.

Why didn't I? Well, in addition to the tweets, they were videoing the event. I wasn't going to hint at this journal! At times like that (when I feel like a deer in the headlights), I remember that I like that this is a quiet backwaters place!

Well, despite the studied silence on my script, I stuck fairly close to what I threatened to say (as close as nerves allowed). Anyway, 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; perhaps I didn't pick the best way to (re)kindle enthusiasm for models, sketches, visualization, but at least I tried! I have more to say on this... another night... I'm tired... pushing rocks uphill is hard, and dangerous, work... Oh, people at the event said lots of nice things about my presentation. Which I take to mean they saw I was nervous and were kind. Grin.

6/22/09 Left Brain, Right Brain--as Metaphor

I should say, for those who are less susceptible to metaphor, that I did not intend for the right brain/left brain allusions to be taken as unquestioned and unquestionable fact; it 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 and feels like a 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." Happy Fathers Day!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!   

6/21/09 Happy Father's Day to all you fathers!

May you have much fun, joy, and fullness of life!

Our 11 year old cooked his dad a delicious dinner (from Emeril's New New Orlean's Cooking--not your beginner stuff), set the table with candles (handmade beeswax candles from the farmer's market--it's really more macho, in a pyro-loving kind of way, than it sounds)... Anyway, he sure showed me up!

6/22/09 Standoffs

Even if it dissipates without violent confrontation, the increased tension created by North Korea's provocative stance can't do the US economy much good. And that ripples out around the globe. What troubling times we live in!

We have to tell our children that there is evil in the world, that not everyone can be trusted because real evil inspires characters like Voldemort. And yet, I get really distressed that distrust runs so deep in our culture that words of recognition and appreciation don't get said for fear of being interpreted as Greek gifts or violent manipulation. Can't we allow that deeply good intentions exist, that appreciation may be genuine and without guile? Not that we should trust where trust would put us in peril. But where it is not misplaced, trust is a platform for social effectiveness. Let's just give ourselves some sensible space on this!    

6/22/09 Congratulations John Zachman!

The first CAEAP "Lifetime Achievement Award" went to John Zachman--obviously that is richly deserved. The EA Professional of the Year Award went to Don Hirst. Having worked with Don on the Doctrine, I can say that he is a gentle but powerful force who keeps people together and gets things done, even when he has to come out of retirement to do them, or seriously help them along, himself!

6/23/09 Visualization

I'm beginning to suspect Daniel Stroe reads my mind; I'm going to have to be careful! I've been looking at software visualization in earnest, and he sent me these links:

Dependency visualization (for example, making layer violations visible) is also the bailiwick of tools like:

Performance analysis tools, or profilers, help benchmark and tune, but we need to push behavioral analysis upstream to include predictive performance analysis, and Jose Fernandez' Cheddar project is pushing this frontier.

So, what else should I take a look at?

And for those of you who were left feeling really antsy and worried for my future with my walk on the wild-side (no technology, oh my word!) talk at CAEAP, how about this:

In another case, medical schools at Yale and Harvard have begun taking students into art museums to increase their observation skills, Pink said. The logic is that in today's world, a huge amount of medical information is already available online. But learning to observe a patient is something that can't be memorized from a checklist.

"Doctors have to be able to ask the right questions," said Pink. "That calls for extraordinary observation skills -- the observation skills of a painter, of a sculptor. So, medical schools are taking students to art museums to make them better diagnosticians. And, lo and behold, doctors who receive this type of diagnostic training are better diagnosticians than those who haven't."

-- "The Pink Prescription: Facing Tomorrow's Challenges Calls for Right-brain Thinking," June 10, 2009, Knowledge@Wharton

We have accomplished so much with technology! Well, yeah, we've been in such a rush to out-compete ourselves, we're in more than a spot of trouble with an overly material, threatened world. But I'm awed and thrilled at what we have been able to do. The problems we've been able to solve. We keep pushing the boundaries of what we sense is possible. Even though we have caused immense sustainability problems, we feel we are capable of solving them--so long as we put our minds to it.

Yes, I am very much in awe of the human mind, and very interested in how we help the human mind do more, create more, solve more of the world's problems and get better at not creating new problems as we do so. Part of our endeavor is rightly to apply technology to amplify our human capabilities. But how often do we get so carried away with technology that we forget that we can apply simple, non-technical tools--too? We forget to enhance our powers of observation, for instance. We feel it would be sheer Gaul to use colored markers instead of Powerpoint to give a presentation. We overlook the simple power of using pictures to amplify the human mind by enabling collaboration of human minds.

So I am very interested in simple things that enhance our ability to create ever more sophisticated and complex, yet (sufficiently) robust software. Yes, I'm also drawn to and value wonderful, awe-inspiring (automated) visualizations. And everything in between. Part of my mission, in this area, is to counter-balance that tendency to value the next best tech-gadget at the expense of getting better at problem definition and problem solution. But that is only part. My full mission is to help architects architect great architectures. And the more routine processing and cognitive load we can pass off to technology, the more we can take on. Systems are becoming more and more complex, not just because people are becoming smarter (both as generalists and as specialists) but because our tools make us so. Our tools for thinking better, and our tools for transferring that thinking more productively to clean code.

Note: I use "problem" in a loose way that will drive some people nuts! I don't mean every innovation or system is addressing a "problem" but rather a set of goals, needs, concerns, frustrations, hopes and aspirations, and I'm using "problem" as a short-hand for that conjoint set of value.

Well, I'm certainly happy to have our field's über-geek pointing to the behind-the-scenes creative process for JibJab's He's Barack Obama♫ video. (And Dana pointed me to a clip of our country's über-nerd revealing his sense of humor♫ at the event where the JibJab video premiered, namely the Radio and TV Correspondents' Dinner.)  

Note: I try to remember to put a ♫ on a link that plays sound, so you don't disturb your family...at 3am.    

6/23/09 CAEAP Talks

Kathie Sowell elegantly used the Robert Frost poem "The Road Not Taken" as the organizing theme for her presentation. Beryl Bellman used a great set of spot-on quotes, like this one:

"Specifically, I would suggest that the effective organization is garrulous, clumsy, superstitious, hypocritical, monstrous, octopoid, wandering and grouchy" --Karl Weick

Beryl's talk was thought provoking and dense with content.  It came at the end of a full day, so it's useful having the slides available to go back to.   

I'm hoping to steal some moments to scan in the storyboard for my talk (and maybe even my graphic notes from the talks from early in the day). I'm sure a better (at least--less nervous) presenter would have executed on the idea with more presence than I did, but I did come up with some innovative tricks to compensate for the (chosen) lack of technology slick. I think that Weick's characterization of effective organizations is pretty spot-on for effective people too. But people, like organizations, still strive for internal alignment, even if they have to compromise at every turn (hence the tendency to appear even more hypocritical than we are). And for me, using hand-drawn images and compromising to meet the timing constraint by pre-drawing some of my talk, and then drawing in key elements live so that the full visual story was revealed on the fly, was a way to stay aligned with the values I was trying to convey.

All that said, I think another week on the presentation (e.g., to fully take advantage of the possibilities of the dual flip-chart left brain-right brain metaphor thing), and it could have been really quite cool, in a retro kind of way. Grin. But the ladies and gentlemen at CAEAP were just that--ladies and gentlemen, and really quite kind, putting on a pleasing display of enthusiasm.

Yes, I did say ladies--not lady, as is so often the case. Kudos to Mark Lane for a diverse audience, and diverse slate of presenters!

And kudos to Mark Lane and Mark Goetsch for making CAEAP happen. Some days I feel like enterprise architects are a threatened species, as we hear about EA program cuts and eliminations. Building the identity and standing of the profession is important at this time, when every branch of the enterprise tree is scrutinized for pruning--and even the branch that designs, builds and maintains the webs of enterprise capabilities is vulnerable!  The trouble with being good at mess management (in the best Ackoffian sense), is that too few understand how to value those who can harness the mess! 

6/24/09 The Superhero Thing Runs in the Family

In keeping with the theme of uniting a nation behind an ethic of addressing the evils and ills of this world--this Obama-gram is from the First Lady:

"There's an old Thomas Edison quote I've always liked: "Opportunity is missed by most people because it is dressed in overalls and looks like work." It's no secret that our country faces some enormous challenges right now, and meeting them will take a lot of hard work. But in that work lies an equally great opportunity -- a chance to serve. And I do believe the chance to serve is a precious gift indeed.

Service has played a transformative role in my life -- bringing me tremendous joy and helping me find the path that led to where I am today. As a parent, I believe service is a great way to demonstrate values and to teach our children firsthand what it means to commit to a purpose beyond ourselves.

It should be a part of everyone's life. From the moment someone can walk to the day they leave this planet, service should be a part of how we give back, how we say thank you, how we express our gratitude for the lives that we've been given.

So I'm deeply honored for this chance to support our United We Serve initiative and Organizing for America, and I hope you'll be able to participate this weekend. Please sign up now to volunteer at a local event:


I'm guessing the next JibJab satire will leverage The Incredibles, extending the superhero theme to the First Family. And what a family it is! Beneath the humor is a deep truth. These times need this kind of good leadership.

6/24/09 Looking to the Future

Bald-faced hornets building a nest on our window (the structure is much bigger now)6/24/09 Wasps and Visualization

We've had a bald-faced hornets' nest growing on the kids' activity-room window all season. This makes for superb (and safe) viewing of the growing colony of wasps, and the structure they live in. The resulting cut-away view into the half-dome nest is wonderful--we can see the structure being built, and the eggs and pupae being tended. The nest began small, with a pocket of eggs, and the structure has constantly been expanded since. It is a great source of inspiration for visualization, because we see not just the structure but the behavior that the structure supports, and all this growing through agile development cycles!

Nice of the bald-faced hornets (which are actually wasps), wasn't it? Dana has had a video camera on the nest for a while, and records the growing nest whenever he thinks about it (and has mini DVs), as this is a pretty unique opportunity.  There was even a dramatic incident which we didn't catch though we saw the evidence. Sara came distressed to us, saying the queen was dead. Indeed, she lay dead on the windowsill with signs of things not having gone well for her. Another queen was already at work in the nest. A revolt? Killed in the storm that had barreled through?Catographer on the job!

The cats, of course, think we arranged all this for their entertainment! And no, I will not be washing the window for the sake of the pictures! When the cats go to "bat" at one of the wasps on the glass, you see how aggressively these females protect their nest! They fling themselves with reckless ferocity at the glass--this can't be good for them, but it also demonstrates how fortunate we are to have glass between us and the colony!

These bald-faced hornets are Nature's pest control--they eat flies and other pests. So we're doubly glad to have them grace us. As for using the walk-way below that window... well, we just have to be careful, but it's not highly trafficked. 



6/26/09 More Questions for the Geek Test

Do you:

○ save dead electronics and appliances to take apart with the kids
   ○ find you're too busy writing code to get around to it

○ draw hearts on the lattes you make your spouse
   ○ draw them right way up, depending on whether its for drinking at the computer (leaving the mouse hand free) or otherwise

○ think a wasp infestation is a great metaphor (architecture embedded in the DNA and community culture, iterative/agile development, constantly doing infrastructure development as a background process, etc.), and record it

Any resemblance to anyone I know, is purely ...uh... intentional.

At the CAEAP event, someone asked if my husband is also a consultant. I said my husband is Dana. He said he was sorry. I laughed. He said he was really sorry. Still laughing, I asked "Who for, me? or Dana?" Later I told Dana. Let's just say it did his heart a lot of good!

6/27/09: Enterprise Architecture Workshop Early Enrollment Discount

Dana Bredemeyer will be teaching the next EA open enrollment workshop on August 31-Sept 3, in Chicago). I guess the Chicago folk were just more proactive, but that's democracy for you. The early enrollment discount deadline is June 29th.


Feedback: If you want to rave about my journal, I can be reached using the obvious traceinthesand.com handle. If you want to rant, its ruth@traceinthesand.ru.cz. Just kidding, 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 commit to using what you teach me, to convey it as best I can, help your lessons reach as far as I can spread them. I try to do this ethically, giving you credit whenever I can, but protecting confidentiality as a first priority.  

Topics from the current month are listed down the sidebar (after the archives and before the blogroll). For those who decry my lack of permalinks because you are desperate to share a quote on your blog or to point colleagues to a particular section—just copy the shortcut from the topic link in the sidebar. It's clunky, but it works. I did say the necessary condition was "desperate."

 Architecture on my mind

Restrictions on Use: All original material (writing, photos, sketches) created by Ruth Malan on this page is copyrighted by Ruth Malan. All other material is clearly quoted and ascribed to its source. If you wish to quote or paraphrase fragments of material copyrighted by Ruth Malan in another publication or web site, please properly acknowledge Ruth Malan as the source, with appropriate reference to this web page. If you wish to republish any of Ruth Malan's or Bredemeyer Consulting's work, in any medium, you must get written permission from the lead author. Also, any commercial use must be authorized in writing by Ruth Malan or Bredemeyer Consulting. Thank you.

Copyright © 2009 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: June 1, 2009
Last Modified: December 01, 2011