A Trace in the Sand

by Ruth Malan

 

 

 

 

Architects Architecting Architecture  

August 2010

08/01/10 Your Co-ordinates

This journal contains notes I take as I explore what it takes to be a great software, systems and enterprise architect. This may be some aspect of the architecting process (like iterationrefactoring and documenting decisions), or it may be a characteristic or skill that is useful to develop (like humor curiosity imagination and persuasion). This is a journal of the more traditional sort--a place to keep track of pieces of my exploration, and a place to write as part of my meaning-making process. Anyway, previous month's entries are linked in the sidebar on the right. Posts from this month are listed by title below the links to the archive, and the Blogroll follows.

8/2/10 Developer in Top 20 Most Creative People!

16 Haiping Zhao, Senior Software Engineer, Facebook

-- 100 Most Creative People in business, 2010, FastCompany

and information visualization:

23 Aaron Koblin, Technology Lead, Google Creative Lab

-- 100 Most Creative People in business, 2010, FastCompany

8/2/10 Design Visualization

X "provides state-of-the-art ... design visualization tools that help you get a deeper understanding of how a project works before it’s built. You can detect certain errors in the beginning stages of the design process—the earlier you find them, the easier they are to fix. Design visualization helps you create better designs, while gaining a competitive edge"

Who is X? Autodesk. The application is building architecture and civil engineering, and their cost structures and the mutability of the construction medium are a lot different. Still, when software failures attributed to getting the requirements wrong can run into millions, even billions, we see that finding design issues while they are cheaper and quicker to change is important. If you think the point is ho hum, compare Autodesk's pitch to IBM Rational Software Modeler's... The point isn't that IBM doesn't have fantastic marketing folk, but rather that as a community we saw what visualization was all about in the thrust towards creating the UML, but then, perhaps, we got a little bored with it? Or, in classic style, we got over-zealous, burned ourselves out, created anti-bodies, and now we have to regain traction. Over-zealous? Well, if what we model puts little distance between abstraction and code, I think that's over-zealous...

8/4/10 Visual Thinking -- My Way!

Christoph Niemann's My Way post is great! (Sorry, it's from back in March; I forgot to check in on Christoph, and his NYT posts are irregular...)

Depending on what you're doing for your summer vacation (or winter, for the other half), this may be salient: Red Eye

More software visualization references:

 

Visualization Conferences:

  • IEEE VisWeek 2010, October 24 - 29, 2010, Salt Lake City, Utah, USA

  • SoftVis 2010 co-located with VisWeek
     

8/4/10 Modeling and Visualization

I like this visual model of the relationships between modeling and visualization:

Image source: Centre for Strategy and Performance, Cambridge University

Their strategy modeling and visualization links page is useful.

8/4/10 Google is Killing Wave!

Google is killing wave--that's an interesting twist! Hitting the streets with Google Buzz and Wave at the same time had to factor. Running a skunk-works in Australia had to factor (you can get amazing stuff done, separated from the politics, but then you're separated from the politics...).

Well, I'm frustrated that Google isn't giving it more time, but that doesn't come close to how bad I feel for the Wave team! I really like Wave, but using it, it felt quite "beta" still. It seems like there's technology there that deserves to be matured. As timing goes, users are being bombarded with everything from Twitter, to Meebo, to Facebook, to LinkedIn and Google's own ventures with Gmail and Google Buzz, and it is a stiff battle to gain traction against all that. And Google let Buzz ride on the coat-tails of Gmail, and that was a great play. It seems a bit odd, though, that a company as resource-rich as Google doesn't give it more time to gain momentum. If one looks at LinkedIn, for example, it was launched in 2003 and it certainly is a lot more exciting social space now than in 2004 or thereabouts.  It would be interesting to understand what factors are weighing in here... Be there tricksy gremlins under the covers, or was it just inertial/attention-swamped users who didn't swarm to use a good thing?

I would love to think that participation was web 2.0 and collaboration is web 3.0 and that Google Wave demonstrated one avenue for rich, distributed, dynamic collaboration giving us a foreshadowing of what is to come... And then, perhaps we like the asynchronous nature of email and Sharepoint and the like...

8/12/10:

A moral lesson this might teach
Were I ordained and called to preach;
For men are prone to go it blind
Along the calf-paths of the mind,
And work away from sun to sun
To do what other men have done.
They follow in the beaten track,
And out and in, and forth and back,
And still their devious course pursue,
To keep the path that others do.

-- The Calf Path, by Sam Walter Foss

Stumbling across that poem was fortuitous, given that Daniel prompted me to wonder if Wave was a sacrificial calf offered to pacify analysts and news hounds... (did you see the cover of the August 16 issue of Fortune magazine?)

Well, I have to add Wave to the "failures" list! And perhaps we'll need to add failures of patience/resilience to failures of imagination and process...

8/5/10 Disney's Mind Map

This by way of Anne Merkelson on The Grove's LinkedIn Group: A visual map created by Walt Disney 53 years ago.

Idea map. Mind map. Or value network map, showing the value network entities and value relationships. :-)

8/5/10 Kind Words

I haven't stopped by this particular section of Eion Woods site in a while, so hadn't seen these kind words:

"Bredemeyer Consulting- Dana Bredemyer and Ruth Malan's consultancy company site. DB is a software and enterprise architecture consultant, who used to run HP's internal software architecture programmes and now runs public training in the same sort of area. This site is maintained by Ruth Malan and Dana Bredemeyer and contains lots of useful enterprise and software architecture references, links and resources."

-- Eion Woods, Software Architecture

8/5/10 Must Read!

Sorry, but no-one told me... So, here's the highest priority item in my Amazon cart: Alex Stepanov's Elements of Programming, 2009. Must? Well, I take note when Bjarne Stroustrup says:

"The book contains some of the most beautiful code I have ever seen."

-- Bjarne Stroustrup

Just kidding--Alex Stepanov was at HP Labs when I was there, and we were all very excited by his (and Meng Lee's) work on the STL.

8/5/10 Design

"Design ... is concerned with how things ought to be, with devising artifacts to attain goals."

-- Herbert Simon, The Sciences of the Artificial, p. 114

8/5/10 Emergence and Complexity

"a native talent for perceiving analogies is ... the leading fact in genius of every order."

-- William James

8/5/10 Summer Respite
 
Lake Monroe at Sunrise

Lake Monroe at sunrise. These were taken with Ryan's Kodak point-and-shoot--it does ok for hand-held in low light. At least it communicates the simultaneous splendor and sweet serenity of the moment. Lake Monroe is shaped like a dragon, and this is the towards the tail end of the dragon in the Charles Deam Wilderness... It's great to have Indiana's largest lake so close by. The "playground" for speeding boats is west of the causeway, and on the eastern side we see few if any people once we get past the first basin. There's the Wilderness, state and national forests, and a wildlife preserve, so its forest and water and wildlife. I love mountains, but I love forests too!

I startled a huge pit viper, and Ryan worked on identifying it (from my description) using my iPhone (yes, camping in a wilderness with dark-dark Milky Way-lit skies, and yet within cellular range). So, we think it was a cottonmouth. Swimming in the lake, we had a neat experience with a spider walking on the water! Ryan got excitedly close to see it, and suddenly the spider started running very quickly across the water toward him and he splashed it away laughing. There are times when I wish the kids would be a bit more discriminating about swimming, for example, where the boats launch--aside from a sometimes greasy film from gas powered boats the water may also be brackish. But I'm also heartily glad they're not squeamish or prissy. And out in open water, it is, well, green, but not ucky.

The spirit and mind renewal of a night camping at the lake lingers, so I used precious time to (begin to) set some of the pictures from the dusk and daybreak to ee cummings poem (larger view here):

 

Recently (6/24/10), Grady Booch quoted E. B. White's "I arise in the morning torn between a desire to save the world and to savor the world. That makes it hard to plan the day." As for me, savoring the world gives me a mind to (help) save it. Invigorates and inspires me. And it is important, I think, for the family to have that graceful weaving of solitary and shared experience in the splendor and tranquility of the lake--which is so heightened at dusk and dawn. In between, there's a cacophony of frogs and other night noises; lest you misunderstand, let me hasten to say, it is utterly glorious--cacophony and all! At my and Sara's bidding, we spent time on the lake shore looking at the stars in the dark-dark of the wilderness before the moon rose. When you live in verdant forests, you appreciate the wide open night sky afforded by the lake! When last the moon was full, we drove out to the lake to watch it rise, and another father and his little girl were out on the dock, but the mother stayed in the car. I suppose she must have been ill or really tired or something... I don't think one could see too many full moons rising over water, could one?

Left hand working culture and strategy; right hand working tactically8/5/10 Time-Orientation and Balancing Now and Then 

Last night I watched RSA Animate's animation of Philip Zimbardo's The Secret Powers of Time (it is a great sketch animation).

Dana uses this image of the architect working, on the one hand, quite tactically to make sure that the right things are being done in the near term to be successful, and on the other, working strategically, making sure that what is done today builds to the value that is sought.

The Zimbardo talk left me uneasy about bucketing people into past, present and future-centric. So I scouted a bit further, and this Zimabardo talk makes things fit together better. Balance, again, is key! I wonder if Zimbardo's time-orientation framework is worth bearing in mind, as a way to look at company and project cultures?

 

I took this photo in the tunnel that leads to the US Capitol from the building that houses the Senators' offices... I don't know who the artist is, but as soon as I saw that, I thought about Dana's right hand, left hand image and have wanted to sketch it ever since (that "for ever" is a matter of months; how time flies). Well, now that I've sketched it, I want to sketch it again, to improve it. Another day. It is almost another day as it is! 

architects must have self-repairing egos -- db

8/6/10 Just Enough Software Architecture

Great news! George Fairbanks book, titled Just Enough Software Architecture, is out in eBook form, and will shortly be available in dead tree form too!

8/8/10 Dean Kamen: Talking of Dings

8/8/10 EA (Visualization) Tools

Right, it's August already! How did that happen? :-) I really need to be several people, then I wouldn't have to juggle so furiously! It totally doesn't surprise me that people feel like they are getting busier and busier and if they had 8 days a week they'd use the extra day -- to do more work (noted in the Zimbardo Secret Powers of Time animation I referred to the other night)!! The thing is, there is so much to learn and do, and it's so much fun to do work you're passionate about! Well, I'm deliriously exhausted, thanks to way too much fun (playing and working) this past week -- and several back-breaking hours recovering the household from the neglect that mounts chaos when one has way too much fun playing and working... :-) 

8/9/10 11:12:13!

8/9/10 Those Golden Carrots

Signing up on the Bredemeyer Resources for Architects site mailing list, Chris G. said:

"Excellent site!"

Simple words, but so powerful!

8/9/10 Future-Oriented Thinking

Scenarios--of the ilk described in The Art of the Long View are useful. Peter Bakker's post on Jeff Hawkin's On Intelligence intrigues me enough to want to read that side of the equation--what equips us to be able to think in terms of the future, when there is also the "we can't predict the future" orientation...

8/9/10 Women in Software

“I used to build more product than team, but now I build more team than product.” -- Julie Larson-Green

About women in STEM: Bias Called Persistent Hurdle for Women in Sciences, Tamar Lewin, NYT, March 21, 2010

8/9/10 In Your Hands

Ok, so I had to do the "notes to self" version, just to show I can work on prying open my mind. ;-) Actually, now I see it, I want to draw hands cupped open, holding decisions in one and culture in the other... We go into the role of shaping culture in The Art of Change: To Lead is to See, to Frame, to Draw. So, no-one has volunteered to review it.

we need to shape factors that delight

And I have to draw two hands molding the heart, don't I? 8/10/10: Ok, so I redrew it with two hands.

Second try: shaping factors that delight

 

Iteration works! ;-) (Just, not on my handwriting... sigh)

Second try at the left hand, right hand imagery. A little better? Sigh. But--I learned something--separate the elements (in this case the two hands), so the whole doesn't have to be redone, to replace one of the experimental parts. Oh. Right. I already knew that. It is a fundamental principle of architecture--independent units create zones of experiment and innovation. :-) And reuse. Etc. :-)

3/26/11: And, as iteration goes, I realized that the right brain should be associated with the left hand, so strategy should be on the left.

Trace in the Sand
Architecture Journal

August 2010

Su

1

8

15

22

29

Mo

2

8

16

23

30

Tu

3

10

17

24

 

We

4

11

18

25

 

Th

5

12

19

26

 

Fr

6

13

20

27

 

Sa

7

14

21

28

 

 

I also write at:

- Resources for Software Architects

- Architecture Action Guide

- Trace In the Sand Blog

 

- Other Interests

- Introducing Archman

 

Papers:

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

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

 

Visualization

- Links to tools and other resources

 

Journal Archive

- Journal Map

2011

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- Current

2010

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December

2009

- January

- February
- March

- April

- May

- June

- July

- August

- September

- October

- November
- December

2008
- January
- February
- March
- April

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

2007
-
January

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

- September
- October
- November

- December

2006
-
February
- March

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

- October
- November
- December
 

August Posts

- Your Co-ordinates

- Developer in Top 20

- Visual Thinking

- Modeling and Visualization

- Google Killing Wave

- Disney's Mind Map

- Kind Words

- Must Read!

- Design

- Emergence and Complexity

- Summer Respite

- Balancing Now and Then

- Just Enough

- Dean Kamen

- EA Tools

- 8-9-10!

- Golden Carrots

- Future-oriented Thinking

- Women in Software

- In Your Hands

- Interactions

- Just Enough is Enough

- Point Worth Noting

- Visualization: Evolution of Pygmalion

- Lizards

- Architect Certification

- Of Thought-Weeds and Wildflowers

- Perseid Meteor Shower

- Microsoft sw vis.

- State of EA survey

- Drawing on the Walls

- Value in Design as Design

- Better Late Than Not

- Visual Meetings

- System Properties or Qualities

- Lessons in Grid Computing

- Pattern Finding

- Quotes To Architect By

- Visual Frameworks

- Signs of the Times

- Change: What the Red Queen Told Alice

- Workshop Scheduling

- Environmental Footprint

- Enterprise and Organization

- Innovation and Leadership

- Lady Java

- Code As Fact

- Booch Artifacts

- Architectural Mechanisms

- Requirements "Churn"

- Chaos and Dragons

- Oh my! Software Architects, we draw fire!

- Software Ninjas

- Re"Tweet" (Sw Vis)

- Motivated

- Sketches

- The Art of Small Talk

- Shattered Dreams

- On The Power of Visuals

- Procrastination

- Visualization

- Changing the Life of a Teacher

- Feedback

Blogroll

Chief Architects

- Charlie Alfred

- Rob Daigneau

- Donald Ferguson (kaput)

- Thomas Lee (discont.)

- Brad Meyer (circa '08)

Chief Scientists

- Grady Booch

- Martin Fowler

Enterprise Architects

- Todd Biske

- Adrian Campbell

- Leo de Sousa

- Chris Eaton

- Roger Evernden

- Tom Graves

- Adrian Grigoriu

- Paul Homan

- James Hooper

- Kristian Hjort-Madsen

-- Alan Inglis

- Janne J. Korhonen

- Nick Malik

- Sethuraj Nair

- Jim Parnitzke

- Chris Potts

- Praba Siva

- Serge Thorn

- Jaco Vermeulen

- Tim Westbrock

Architects and Architecture

- "Doc" Andersen

- Tad Anderson

- Jason Baragry

- Simon Brown

- Udi Dahan

- Matt Deacon

- Louis Dietvorst

- George Fairbanks

- Kevin Francis

- Sam Gentile

- Simon Guest

- Todd Hoff (highly recommended)

- Steve Jones

- Frank Kelly

- Philippe Kruchten

- Sjaak Laan

- Dave Linthicum

- Anna Liu

- Ruth Malan

- Nick Malik

- Chirag Mehta

- JD Meier

- Gabriel Morgan

- Robert Morschel

- Dan Pritchett

- Chris Potts

- Bob Rhubart

- Arnon Rotem-Gal-Oz

- Carlos Serrano-Morales

- Shaji Sethu

- Leo Shuster

- Collin Smith

- Brian Sondergaard

- Michael Stahl

- Daniel Stroe

- Gavin Terrill

- Jack van Hoof

- Steve Vinoski

- Mike Walker

- Rodney Willis

- Eion Woods

- Brian Zimmer

Architect Professional Organizations

- CAEAP

- IASA

- SATURN

Software Visualization

- Adrian Kuhn

- Jennifer Marsman

Domain-Driven Design

- Dan Hayward

Agile and Lean

- Scott Ambler

- Alistair Cockburn

- NOOP.nl

- hackerchickblog

Agile and Testing

- Elisabeth Hendrickson

- Elizabeth Keogh

Software Reuse

- Vijay Narayanan

Other Software Thought Leaders

- Jeff Atwood

- Scott Berkun

- CapGeminini's CTOblog

- John Daniels

- Johanna Rothman

- 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

- Tim Brown (IDEO)

- BoingBoing

- Mary-Jo Foley's All About Microsoft

- Gizmodo

- Dion Hinchcliffe

- Oren Hurvitz

- Diego Rodriguez

- slashdot

- smoothspan

- The Tech Chronicles

- Wired's monkey_bites

 

Creativity

- Marci Segal

 

Social Networking/Web 2.0+ Watch

- bokardo.com

- Mashable

 

Visual Thinking

- Dan Roam

- David Sibbet (The Grove)

- Scott McLoud

 

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
 

Comics

- Dilbert

- gapingvoid

- xkcd

get your hands dirty--on paper (and in code, but by modeling on paper whenever that is good enough, or at least at first)

Someone asked if he could use some of my drawings in a paper for a conference, saying that some are "pretty good." What would seem moderate in another context, is high praise indeed when it comes to even the best of my sketches! Indeed, my drawings are horrid (my handwriting too), but when they work out at all, it is because of the saving grace of the representation of an important idea in visual form.

I could take drawing lessons, or practice sketching. Should -- if I want to be so brazen as to put them in my journal! Oh, right, that's not much more brazen than putting my words in my journal. :-) (Or I could just watch Ole... :-)

8/9/10 Interactions

Some sketches from the sketchbook in my purse prompt a post:

We might get a user story "right," in isolation, but in the interaction between the system and many users, in many contexts (some we never envisaged), and many permutations of potentially simultaneous user stories, it gets beyond complicated. It gets complex. I only just came across this article in the NYT: It's Complicated: Making Sense of Complexity, though you no doubt recall I pointed you to (but I have to remind myself of) Andrew Johnston's Architects - Masters of Order and Unorder? post. Even though this is true, it doesn't mean it doesn't help to "sense-analyze-respond" in order to create a better initial structure that we will evolve with "probe-sense-respond" targeted experiments, then incrementally evolving systems, then deployed--evolving--systems. And yes, some of what we do will be in the "chaos" category where we simply go by gut feel actions and optimism--but hopefully we can cordon off these areas of greatest uncertainty.

structure must support and enable system functionality (use cases/goals, user stories, capabilities/features, etc.) and properties emerge from interactions, so we consider system behavior when we design the system structure, but structure is posited to think about behavior. Architecting is non-linear!

Architecting is inherently non-linear. We are finding things out, and our discoveries mean we need to backtrack and rework--better if we're just reworking ideas and rough sketches! But some of our thinking and learning can only happen by roughing up the system in code, so we do that--acap (pronounced asap; as cheaply as possible; grin). Even once the system is pretty mature, new areas of evolution may open up fresh areas of experiment--so we'll conduct thought experiments and "experiments on paper" modeling aspects of the system and walking through them with other experts, and we'll prototype, and incrementally evolve the system. So we move between structure and behavior, between detail and higher level abstractions, between views supporting different concerns. And between code and design as the intentional process of making things more the way we want them to be. We integrate design ideas from many sources. We refine, we revise, we reify, we redo. If we have to do all this in a quickly expanding code base, we soon lose flexibility (or the tolerance for it), so we must allow the architect (team) to scout out in advance--in advance. Just enough. How much? It depends. The risks and the challenges, and the scope of the value set, are going to differ from one project to another.

Yeah it's messy! But better we let the process be messy than the structures we create thereby! It simply acknowledges the interplays and influences. I could make it even messier by drawing in the iteration. :-) Um, oh, right. It's my drawing that's messy. Well, it conveys the right sort of stuff then. :-)

Visual architecting:

  • Multiple influences: requirements and constraints, capabilities, responsibilities; styles and patterns; ideas and experience; metaphors/analogies;  dives into detailed design and prototypes in select areas; modeling interactions
  • Iteration: moving fluidly, driven by the architect's judgment (with the aid of the risk, challenge and uncertainties radar on your architecture dashboard) across models at the same level of abstraction; across models at different levels of abstraction; between requirements and design; creating prototypes, getting feedback from various stakeholders and experts; etc. All of which makes the Software Architecture Decision Model (or view model, if you prefer that terminology) hugely important, for it provides an organizing framework for the decisions (at various stages of maturity from initial-tentative to high confidence/put under change management because the cost of change now needs to be considered explicitly). 

8/9/10 A Historical Note: Just Enough is Enough Already!

Just Enough Software Architecture. That is the title of George Fairbanks book, and it is a good one! You no doubt remember (if you followed the Fusion Newsletters I edited, and the Fusion website I was principal editor and writer for--back in the mid-90's) that one of the key differentiators of Team Fusion was that it was a just enough method (or JEM), a term we coined. Oh right, and Chapter 9 of The Handbook of Object Technology, Fusion 2.0: A Process for UML--that's the chapter by Derek Coleman, Todd Cotton and I--begins 'Fusion 2.0 provides an effective software development process and "just enough" method to manage project risks.' And we have long talked about just enough design upfront (JEDUF), contrasting that with BDUF. So, you see, I (and Charlie Alfred, who has, in key ways, led my thinking in this area) very much align with "just enough software architecture" and a risk-driven approach.

Charlie, of course, tends to simply say Enough Design Up Front, or EDUF rather an JEDUF. Now, I'm sure you remember Emerson's quip, but I'll repeat it in case you haven't had the pleasure of stumbling on it:

"Simplify, simplify."

        H. D. Thoreau

'One "simplify" would have sufficed.'

        Ralph Waldo Emerson, in response

That is applying a key principle of architecting to the statement of that principle of architecting. It is alternatively stated as Occam's Razor, though Emerson's (ostensible) version is the most terse!

Eb Rechtin, one of the founding father's of system architecting, and a proponent of heuristics in the art of architecting said:

"simplify, simplify, simplify"

He also said:

"communicate, communicate, communicate"

which I think illuminates his use of 3 "simplify"s!

So, just enough, or enough. Either way, it's a good idea. Hard, you may say, to execute on. But that is why experience is a value in architecting. You want some "can do" enthusiastic optimism, but it is also good to have that voice of experience illuminating the risks, challenges and uncertainties so that the design addresses value and challenge and risk. How we want things to be, after all, is very much about value, but value that isn't unraveled by structural flaws!

Just. Oh yeah--that explains a lot, doesn't it?

I have, so far, only dipped and dived around in Just Enough Software Architecture to get a sense of the coverage and George's approach to and thinking about architecture, but that has left me wanting to read further. 

8/10/10 A Point Worth Noting

I scanned in a backlogged sketch and adding it where it belonged, I was reminded that some pretty important stuff gets buried in the least obvious of places! You might like to read this paragraph, since you probably skipped that post even if you were reading along back in June! :-)

8/10/10 A Visualization: Evolution of Pygmalion and Other Tales

This by way of a Codemap tweet:

8/10/10 Lizards

This is Alistair Cockburn reading one of his poems: The Hike 

8/11/10 Architect Certification

The Open Group:

  • Level 1: Certified IT Architect – able to perform with assistance/supervision, with a wide range of appropriate skills, as a contributing architect

  • Level 2: Master Certified IT Architect – able to perform independently and take responsibility for delivery of systems and solutions as lead architect
  • Level 3: Distinguished Certified IT Architect – effects significant breadth and depth of impact on the business via one of three advanced career paths: Chief/Lead Architect, Enterprise Architect or IT Architect Profession Leader

-- The Open Group, IT Architect Certification Program

8/11/10 Of Thought-Weeds and Wildflowers

It occurred to me...  what you (no doubt) think of as thought-weeds, I think of as wild-flowers. So you think they should be pulled, and I think they should grow in abundance. :-)

Thinking about documentation (a conundrum that plagues our field), I came back across this:

Can we stop at conversations and drawings? Even for more complex systems, that can be good enough to get going, and in any event is irreplaceable, no matter how complete our specification. But conversations as the only architecture communication vehicle, rely on the person(s) who has the architecture in their head being there. What, you never want to go on vacation? You never want to go home at 5pm even once a week to take your son to soccer practice? You always want to be working on this system? Really, for the next 10 to 20 years? What if you get hit by the proverbial bus, or poached by a start-up offering you shot at CTO of the next big thing? And now how about this: do you remember what you (personally, or the collective you, the architecture team) were thinking when you made one choice over another, three years ago? three months ago? three days ago? And just how did this mechanism work anyway? Why did we think this would work? Documentation creates a record of our decisions, for ourselves, for our teams, and for the future. And documentation explains and justifies our decisions.

-- moi, Architects on a Pedestal? Or Architects for Target Practice?, 5/15/06

8/11/10 Perseid Meteor Shower

Those who use this spot as their natural soporific: you can get along without that sleep for a night or three--get outside (away from lights) and look up! The Perseid meteor shower peaks Thursday and Friday nights!

Ok, if that doesn't do it for you, then this (by way of Adrian Kuhn's tweets) might: Scaling Twitter: making Twitter 10000% Faster, by Todd Hoff

This is also a great read: Choosing Consistency, by Werner Vogels, February, 2010

8/11/10 Microsoft and Software Visualization 

Interesting tweets:

#codemap: Unfaithful @akuhn is cheating on me, he works on http://research.microsoft.com/codecanvas this summer instead of me and his thesis   [7/25/10]

#akuhn: Microsoft just open-sourced ZoomableCanvas, the core control of #codecanvas! — full coverage on @kaelr's blog, http://bit.ly/a5pkSj  [8/9/10]

Microsoft has several projects going on in the spatial representation/code visualization space.

And in the "Yay PowerPoint" category--this is a great slideset (I don't know if Marko used PowerPoint, but you'll get the point), by way of #akuhn:

8/12/10 The State of EA Survey

"Stimulate your own thinking on EA strategies -- including EA frameworks, architectural models, certification, business architecture, and more -- when you take our short survey on Enterprise Architecture in 2010: http://www.keysurvey.com/survey/322064/b8ad/ . To thank you for your time, you'll receive a complimentary copy of the Cutter article, "Applying Enterprise Architecture: Seven Principles for Making It Work." In it, you'll explore what was needed to develop and mature an EA practice at a large U.S. utility."   -- email, Cutter Consortium, 8/12/10

8/12/10 Drawing on the Walls

My copy of Visual Meetings hasn't yet arrived, but the commentary is starting to flow, providing a glimpse of what is in store. This, by way of Anne Merkelson:

"Yes, not only are we moving towards using music to enliven meetings to create new ideas and new decisions, we are also returning to the wisdom our ancestors to use pictures to enhance the words. Fascinating that as life gets more complex, the more we return to our predecessor’s roots to engage the human spirit. What it takes to to break free new thinking to create exciting new futures, eh?"

-- Marci Segal, Cave drawings engage people in meetings – visual thinking, August 4, 2010

David Sibbet and The Grove introduced us to the value of graphical facilitation to make group work effective, productive and fun (rather than the negative patterns of entrenched, divisive behaviors that can come of bringing people with different perspectives and job turfs together). When I joined HP's Software Initiative (from the Software Technology Lab in HP Labs), I discovered that a "rite of passage" for that HP-internal consulting group was to take The Grove's graphical facilitation training. I confess I was as much a skeptic as most any other software engineer. And remained so for a good while, but observing my peers in the Software Initiative, and their work with development teams doing complex systems development (product platforms, teams distributed around the globe, etc.) in HP, I gained enough appreciation for the the value to tentatively venture into "drawing on the walls" to facilitate group work. Well, of course I had been drawing on the walls (and flip charts) in the Fusion, and then UML, modeling and design patterns work I was doing with software teams, but I hadn't ventured into vision and strategy facilitation with multi-functional participation. Now, anyone who has seen me do a Competitive Landscape Map (an outgrowth of Grove's Context Map) knows that my (messiest) drawings and handwriting in this journal are representative. (I'm no David Sibbet!) And yet most people get the value of that mechanism for structured brainstorming and collaboration despite my lack of skill. And I think, actually, in part because of it. They see me going out on a limb, and they enter into the spirit of the thing with openness and warmth. So, I guess I'm unabashedly drawing on people's intrinsic kindness and goodwill, but what we draw on gives something back too. Right? Positive expectation is a crucible for good things to happen.

Some references from my journal:

In addition to drawing me into group graphical facilitation, David Sibbet is also responsible for drawing me into Second Life. Grady Booch might have, if it weren't for being able to punt and just watch him in SL on YouTube or InfoQ. :-)  Anyway, if you haven't visited The Grove on SL, I highly recommend it! It really instantiates a vision of what businesses can do in SL that helps further what they do in RL. 

8/12/10 Value in Design as Design

In the building architecture space, the value in architectural designs (from landscape drawings to blueprints) is self-evident. A market has grown up around the designs themselves. We can buy architectural designs for homes, or we can buy the services of an architect to create these designs, and a price is attached to them. We can create or buy the plan as part of a dream we hold, an intention we have for ourselves. Or we can have the plan built. We can compare architectures to learn from them, or to choose among them. The architecture allows us to test and gain confidence in our functional and aesthetic choices, as well as in the structural integrity. All of this is to say, the architecture has implicit and explicit value. And there is a market for this value. Even when no building has (yet) been (or may never be) built, it has recognized value. How much value, will depend on the (functional, structural and organizational) complexity and the technological and aesthetic requirements. And depending on structural complexity and technological requirements, the design may need to be complemented with structural designs by specialist structural engineers. More design, and a higher price tag, signaling higher value.

Now, some organizations have had architects for decades (you'll remember Dana had the title of Software Architect in the Operating Systems Lab around 1988, and beyond). I haven't seen a study, but given my window across industries, the architect role has become pretty well established in organizations doing complex systems development. Wherever there is an architect drawing a salary, we can say this is an expression of recognized value that the organization places on architecture. They may not fully understand it. They may not know what exactly to expect and get from their architects. And some will question the value. You'll find the same thing in the building construction space, where everyone from structural engineers to various construction contractors can make some pretty snide remarks about the architect. Ok, so there's some fuzzy feeling that architecture provides value. But because we're building proprietary systems, we don't have a direct open market to help us assess that value. We do have an indirect market. We hire off Amazon's EC2 architects as fast as we can get hold of them, to hire in, effectively, the designs and patterns they carry in their heads. Once an architectural genre converges on a dominant design, we don't have to pay a price premium to gain the designs embedded in the experience-set of those that blazed the bleeding edge.          

Someone to watch though, is Nathan Myhrvold, who is making big business of inventions, and looking to make an invention engine a market capitalizable proposition. So not only are inventions -- not products -- the revenue stream, but they're looking to take what was an extremely well-funded start-up, public. Hopefully that will help us raise the visibility of the value in inventive designs that create compelling, distinctive business value. Yes, ultimately these designs have to be implemented to garner that value, but if there can be a market for inventive designs (patents included), then designs have value! And if they have value, we can make a case for investing, sustaining and growing that value. Now we are intuiting that this is the case, and it is why we have architects. But we also struggle with investing in explicit design when our community messaging is that there is no value without code, code rulez, code on. But if we say code is how we realize the value in an inventive design (and improve the design, of course), we turn the value statement around. Instead of saying code is primary, we say value is primary and designs and code are both essential to creating value. Then we can ask how much of the design can and should be done in the medium of (developing production) code, and the answer will depend on complexity (including organizational) and novelty and risk. Creation comes out of chaos, but chaos always threatens to regain supremacy, so we need the architect to wrestle that dragon--that transmogrifying beast.

8/12/10 Better Late Than Never

This by way of The Grove blog“The only thing obscene about it is the amount of time you are liable to spend there” : Chart Porn (http://chartporn.org/)

And this, by way of Chart Porn, is really, really funny: Some thoughts on Maslow's hierarchy. Lunchbreath totally gets dogs!  And robots!

8/14/10 Visual Meetings

My copy of David Sibbet's book arrived. I recommend it most enthusiastically to architects--to anyone, really, who is trying to get big things done with and through people. I like to reframe design "meetings" to working team sessions, and visual modeling of various kinds is a mechanism to create a shared collaborative thought-space -- an externalization of the reasoning we might conduct in our heads but which, because we make it visible to others, becomes a forum for interaction, for clarifying assumptions, for making new connections, for asking new questions. "Group think" is bad, yet team thinking, when creative, collaborative, respectfully surfacing ideas, issues, questions, etc., is integral to innovation in an age where the creation of systems relies on diverse expertise, experience, perspectives, ...

Perhaps I make some smile at my "draw on the walls" because it seems naive or "retro" in a tooled world, but it is a recognition that comes out of much experience in a tooled world that our humanity is precious and vital to innovation, and it means we need to leverage the greatness that comes of human collaboration and from our ability to use tools to extend what we are capable of. Not one or the other, but both. So please don't think I am in the camp of "draw on the walls" and be done! We need to mature our designs, and as we do so, we need to mature our documentation of the design elements. And always, that is throughout, we need to keep track of our thinking--first sketchily and then more formally. First more in conversations with jotted notes and sketchy diagrams (and digital photos), but then through more crafted models and words. And then reflecting what we built in models of the code that we contemplate and reason about, to help us further mature the design as well as to simply tend the system as we grow it and apply it in new ways.

At any rate, Visual Meetings will put important tools into your toolbelt so you can help teams go from a "stop talking, start doing" mindset to one where talking is an important mode of doing -- the doing that happens when at least two people get together to find problems, define and (strategize how to) solve them. As we come to realize that collaboration, not just within the development team, but with marketing and business analysts, with the management team, with the ops team, etc., is vital to creating innovative systems with great fit to intent and to context, we realize that bringing these multiple perspectives together fruitfully is important.   

8/15/10 System Properties or Qualities (Quality Attributes in SEI lingo)

Mindmapping tools can be used to create such "utility trees." I suppose quality refinements with QAS or test cases at the root nodes aren't, strictly speaking, "utility trees" though they derive in form from utility trees.

I liked this use of a mindmap for navigating code smells, although the links are broken.

Qualities and Mechanisms

8/17/10 Lessons in Grid Computing

Mark recommended this book at the last open enrollment Software Architecture Workshop:

Here are some words from the overview on Amazon:

"Packed with truer-than-life stories, stimulating characters, and unique IT analysis, Lessons in Grid Computing finally declares:
* Our systems will not "talk to each other" if our people are not talking to each other
* We must transform ourselves to the same degree that we want to transform our systems
* To correct problems in our information systems, we must first address the problems between the people that build and support them"

Sorry it took me a while to post this--it comes highly recommended by an architect I much admire; I had just misfiled the note with the workshop logistics stuff, and by chance came across it tonight.

I believe it was also Mark who pointed us to this excellent piece of our tribal history: Real Programmers Don't Use Pascal (1983).

8/18/10 Pattern Finding

This slide in Ryan Coleman's deck is eloquent:

Image Source: Ryan Coleman, Designing for Visual Efficiency

8/18/10 Quotes To Architect By

I stumbled on "10 Photography Quotes You Should Know" by way of Ryan Coleman (who is active in the Viz Think space), and especially like the first:

“ You don’t take a photograph, you make it. - Ansel Adams

Read more: http://digital-photography-school.com/photography-quotes#ixzz0wy8rCzmm
 

"You don’t take a photograph, you make it." - Ansel Adams

After I get done with To Lead, I'll take a cut at a list for system architects.

8/18/10 Visual Frameworks

8/18/10 Signs of the Times

Since I'm not journaling ;-) while I finish To Lead is to See, to Frame, to Draw... From time to time I see signs and later wish I'd taken a photo--like one in town which said "ONE WAY or another" (the last part being a graffiti add-on). Here are some signs for fun:

8/19/10 Change: What the Red Queen Told Alice

When Keith Frampton reviewed The Art of Change: Fractal and Emergent, he prompted a series of explorations and I told him I was so happy because it was my intent and hope that the report would stimulate conversations and explorations. At the same time, what I was trying to do, was to both motivate the second half, and provide an example of what the second half (what became the second paper, due shortly) would describe. In other words, I wanted to offer an example of leadership--of seeing a need, framing it, and beginning to draw. But of course, just a paper can't be a full example of drawing people into the conversation, into shaping change, for that has to be highly dynamic and interactive. I achieved what I hoped, if it motivates and if it launches conversations, stimulates thought, nudges a change in mental models and prompts (shifts in) action.  

With that framing, you'll understand that I was excited that Andrew Parris both referred to the paper as motivating, and drew Steven Spear's The High-Velocity Edge into the conversation:

"here is my comment to this motivating article:

This article makes me think of the book I just read, "The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition", on this topic of organizational change and innovation. I think that the author Steven Spear's insights from Toyota on how companies can develop the disciplined skill of innovation provide helpful guidance on how any company can continuously improve towards excellence in any market condition.


My summary of key ideas in Steve's book The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition, and from his webinars on this topic:

  • Some organisations are capable of achieving and sustaining exceptional levels of performance that gives them and helps them continue to maintain a significant competitive advantage over their peers

  • Exceptional performance requires the capacity to generate and sustain high-speed, broad-based, non-stop, improvement and innovation

  • Complex systems (which engage many people across different systems and functions, in non-linear relationships) hinder exceptional performance; these complex systems are impossible to design right from the start, but can be perfected through relentless, continuous improvement and innovation (discovery)

  • Innovation is not the “kiss of inspiration” on the brow of the genius; rather, improvement and innovation are rooted in a disciplined set of skills (which can be learned, practiced, applied, and improved) around the basic science of designing, operating, and improving complex systems of work

  • Senior leaders serve a critical role in the design and improvement of systems, and are responsible for cultivating these skills in their people

  • The four capacities of high-velocity organisations:

1. Specifying design to capture existing knowledge and building in tests to reveal problems
2. Swarming and solving problems to build new knowledge

3. Sharing new knowledge throughout the organisation

4. Leading by developing Capabilities 1, 2, and 3
"

-- Andrew Parris, comment on The Art of Change: Fractal and Emergent sent to Cutter, and copied to Dana and me, (personal email), 8/19/10

Well, truth be told, I would simply be excited that someone read the paper (aside from the editors and reviewers who were most kind)!  ;-) But I'm thrilled to have "motivating" applied as an adjective, and the conversation extended with a valuable reference! [Ah, another book to read. Well, as soon as it arrived, Dana made off with my copy of Elements of Programming, so the 3 books I'm reading at the moment are light--useful, but readily accessible even in a dip-and-dive fill-spare-moments reading mode. Stepanov is wonderful, but distinctly not light reading!]

And, truth be told, Dana had to read so many versions of The Art of Change: Fractal and Emergent while we were writing it, I don't believe he has read the final version! He'd object that he's read 90% of the final version (multiple times at that), or 150% of the final version, depending on whether you're counting what was cut, or what was added! :-) One of the worst things about writing a report like that, is how many times one has to read it--the rounds of copy-editing alone were enough to make me thoroughly, thoroughly sick of myself! At that point, one has to focus on the details, and I know if I come around to being able to stomach reading it again, I'll find big things I'd want to do differently. Yes, that sounds familiar, whether it is code or papers, we keep learning. It's most inconvenient, really. ;-)

8/19/10 Workshop Scheduling

We are working on the open enrollment schedule for the remainder of 2010. We will fit in an EA workshop, and at least one Software Architecture Workshop in the US (in addition to the two in Europe in September). Ping me if you want to influence where we hold these. We looked at Washington DC, but the two weeks I'm available, there are big conferences going on in DC making it hard to find a suitable venue. So, for the SAW we're looking at Boston and/or Houston at this point.

The bigger question is around the Architectural Leadership Workshop. We might float one and see if it fills sufficiently, but it is a tough class to fill even in good years. In case you hadn't noticed, this is not the best of years for "discretionary" budget items like training, especially soft skills training. It is ironic, because this is exactly when compelling leadership is needed. I mean, who doesn't need architectural leadership. Yes, the title is a play on words -- competitive leadership through architecture, and architects as great leaders.

Software Architecture Workshops (to be taught by Dana Bredemeyer in English):

  • Düsseldorf, Germany, September 13-16, 2010

  • Eindhoven, The Netherlands, October 4-7, 2010 [last I heard, there were only 2 spaces left open]

8/19/10 Environmental Footprint

Here are some infographics that carry a double-punch (making our impact visual, and making the point that visual has a powerful impact):

8/19/10 Enterprise and Organization

Yesterday I encountered an energetic debate about the definition of enterprise versus organization. At their school's music concert in the Spring, a dad who is prominent in the music community in Bloomington, characterized Ryan and Sara as "enterprising." In this school, in a town that is a strong attractor to musical talent, there are a few little "next Mozart" contenders, and the next Joshua Bell, while my kids are charming but far from musical savants. So you'll understand that "enterprising" in that context was, um, enterprising! We want to be so precise about things that are inherently context-dependent and fuzzy around the edges. So we're not satisfied with TheFreeOnlineDictionary's enterprise = "business organization." Of course, I'd like enterprise to be flavored with that "enterprising" slant: "Willingness to undertake new ventures; initiative."

'We can't define anything precisely. If we attempt to, we get into that paralysis of thought that comes to philosophers… one saying to the other: "you don't know what you are talking about!". The second one says: "what do you mean by talking? What do you mean by you? What do you mean by know?"'
-- Richard Feynman, The Feynman Lectures, Vol. 1.

I'm just kidding. Really what I want is for everyone to define architectural styles the way I do. :-)

Eb Rechtin was very practical. Tomorrow I'll dig out how he talked about architecture definition. Right now, I'll get into trouble if I don't get the kids to bed. Drawing lines is important, and knowing when to be flexible on the lines is too. That said, I'm not very good at holding the line on bedtime...

8/23/10 Innovation and Leadership

I hope that you found The Art of Change: Fractal and Emergent useful, both personally and as a way to open discussions about the relationship of strategy and architecture in the spheres where you (would like to) have (more) influence. The point, given the fractal metaphor, being that this discussion is just as relevant at the application or product level as it is at the enterprise or product family level. And if Part One: Fractal and Emergent leaves you eager for Part Two: To Lead, remember that we like to involve a spectrum of our audience in the review stages, so that we can improve the report given different perspectives, questions, and suggestions. Part Two is about leading, innovation, persuasion and influence, collaboration, etc.

Journaling in January, I wrote:

...  but especially to architects who lead--because taking on leadership is taking on meaning-making for a chunk of peoples' work-lives and that is a big deal! We don't have to take our team to Australia and fabricate urgency--it is in each of us already! It just has to find a target, and that is what the leader does--the leader crafts a compelling and urgent message: this is worthwhile, this is why, this is how soon, this is how it will be great. To lead is to see, to frame, to draw. To lead is not to drive. Rather it is to enroll, inspire, invite, empower, so the team is intrinsically driven by being involved in something meaningful and urgent. To lead is to demand, but not to command--to align high aspirations that demand unflagging commitment to giving of one's best and holding peers to a design aesthetic while getting the job done.    

And I love it when a paragraph is a book of knowledge folded tightly into a few quested, sought, wrought words. If I say the last paragraph is one such, you'll dismiss it and me.  But think about it! To lead is to see: to observe; to imagine; to see the human aspirations, frustrations, desire; to find the opportunity. To lead is to frame: to craft the compelling message, the visual and verbal rhetoric that helps others see; that positions what must be left behind and what must be built in the minds and experience of women and men. To frame is also to structure, without filling in the detail. To lead is to draw: to draw people in, to enroll them, to align their action, to create a pull so that driving is not necessary. To draw, we literally draw in pictures and words, and in doing so we draw out what is in the minds of individuals, we draw on their experience and talent. We create a shared picture that compels.

So those are the two paragraphs that inspired the form of The Art of Change: To Lead is to See, to Frame, to Draw (which became too long to be one Executive Report, and got chunked into two). When I wrote that, I had sections of the report written, but I was looking for a way to organize the material. And there it was.

I went back to Kent Beck's One Team post -- I admire the humility of sharing that personal journey with its growing awareness, and I wonder if Kent would get value from Getting Past ‘But’? It is interesting that we have been learning from the XP/Agile/Lean community (and see ourselves part thereof), while it has been embracing more of what we have long espoused, as scaling issues are faced and braced, and design becomes ever more necessary given sophistication in expectation and complexity compounds.

Anyway, from there,  I went to Steve Blank and from there to Ash Maurya's site and was reading around his blog--I like it! This post, for example is a great read: There is an "I" in Vision. And this line is so well put:

"The challenge isn’t building out a solution but validating that you have a problem worth solving in the first place." -- Ash Maurya

Of course, we build and iterate on a solution to find out, but if we can fine-tune our hypotheses about the problem before we build out a solution, so much the better. Yes, it strikes a Getting Past ‘But’ chord. Smile.

Hopefully one of the take-aways from The Art of Change is that we need to think of the strategy-architecture tandem fractally, and one of the off-shoots of that is taking on more responsibility for nurturing a synergistic business-technology strategy relationship at our level of scope. That doesn't mean trying to wrest control from the management tree! Rather, it means understanding the business from multiple points of view, not just from the point of view of the "guts" of the systems that the business is intertwined with, and stacked on top of. So hopefully you will find posts like this useful: "How I Document my Business Model Hypothesis" -- and then you can try it out on your product (or enterprise).

Another complementary and crucial view is the "identity--value propositions--capabilities" strategy framework. :-)  (Remember, value propositions include value propositions to shareholder/owners, to customers and channel, to employees and other value partners.) 

Oh, I should perhaps add that the problem-solution distinction that Ash makes, could usefully be viewed as a way to find the compelling, distinctive value proposition, and so is subsumed in the statement of the UVP (unique value prop).

In our framework, we distinguish key partners (and others in the value network) in order to determine what value they contribute to our core value propositions, and what value we need to offer value partners, to make it all work, systemically. It is taking an ecosystem frame, and thinking about the flows of value. This is useful to do at different granularities. For example, if you're providing common services to several apps team, you want to think about the value flows. In that case, your primary "customers" are internal teams, and they are as make-or-break as their customers.

At any rate, I need to draw out the relationships between our Visual Strategy Framework and the Business Model Canvas. Just as with VAP and 4+1, there is a mapping and the approaches are complementary.

8/23/10 Lady Java

Did you see the "Lady Java" video created for JavaZone 2010 (featuring Jenny Skavlan as "Lady Gaga")? As Grady Booch warned, the lyrics may be iffy for workplace listening.  I'm happy there are people who have the creativity and sense of humor and gumption enough to do that! And sad that there are people who didn't get the humor and the talent and fun! I mean it is stand-alone slick and witty, and then you layer the Lady Gaga play on top of that and it is outrageous good!

It is classic viral-able meme stuff, and as pop-tech commentary available for opt-in viewing, I think it is an awesome piece of work... though possibly not so great for captive business/educational settings (like a conference). And possibly not so great that it invites comments like: "My boss uses a whip too, but she's not that hot :(" Still, we are the culture that pop-art reflects, and I think this parody-commentary is artful and artistic. (The Java 4Ever trailer too, but again it is full of adult innuendo, so caution -- you should probably assume that the ending is not-workplace-appropriate, though the sex is implied.) Cuing off Lady Gaga's Bad Romance-style music videos is a smart move for anyone who wants the weight of social precedent behind them for conference commercials that lean on "sex sells." 

Both videos play with narrow-mindedness, and the "religious" zeal we geeks are prone to. I'm still left wondering, though, about using a sex pitch to sell a conference in a field that is predominantly male. In Java 4Ever, the girl is also using a PC, but if they didn't want to convey domination, they could have chosen a different position. That is the kind of trouble you get into, when you want everyone to "act grown-up, and open-minded." If we don't want our field to be seen as dominated by tech-machismo (the tech equivalent in tribal adulation terms of the sports-jock), we should watch the images we use to sell the field to up-and-coming developers. 

As cultural commentary and art, I think the two videos are great--they speak to the realities of our world. Besides, we do need a cultural image boost on the lechery front...

8/25/10 Code As Fact

Grady Booch has memorably said "the code is the truth, but not the whole truth"  (actually, Grady ascribes the "code is the truth" to someone else, but I forget who to).  "But not the whole truth" goes after what is missing from the code. This is crucial! For example, we don't need to tell processors why so the rationale for design decisions is not expressed in programming languages. We might remember to comment crucial assumptions, but implications of decisions and alternative approaches considered but ruled out, also get left out of the code. We apply the principle of separation of concerns variously in software design--and documentation design. And when we variously separate concerns we're going to be variously partitioning our "truth" too.

That said, I want to go back to "the code is the truth." I mentioned this in conversation with Dana, and he said he likes to shade it a bit differently--using, instead, "The code is fact." This notion that the code is the object, and truth corresponds with and relates to the object, but isn't itself the object, may be helpful. I guess it is similar to the data--information--meaning kind of distinction. Software visualization that reflects structures and properties of the code, claims to reflect the truth because it reflects facts. But it is in the selection of facts to reflect, that we are getting at the visualization designer's sense of some dimension of truth that is worth wrestling with. So we can usefully ask questions such as "what is the meaning we want to surface from the fact of the code?" and "how do we assist ourselves in getting more informed about the state of the code?"

We act so much like there is competition between architecture and agile development, between models and code, between architects and developers, between this "tech-religion" and its zealots and that. This competitive "war of the worlds" kind of stance has the goodness that it drives the pursuit of excellence in these various approaches. But pragmatically, we need to be about context-sensitive collaboration and integration, co-operation and synthesis.

Fact is essential to truth, but our notion of truth lets us construct higher order principles, values, mechanisms that enable our development "tribes" to create new, consistent facts that build to the truth we seek.

Well, this could take all night, because we could also play with it this way: it is hard, and even impossible, to get the full truth about the whole from the code. There are truths about the system that are not extractable from the code, although we may inspect the code for consistency with the truth. 

8/25/10 Booch Artifacts

Googling for Grady's attribution of "the code is the truth," I came across some slideware I hadn't seen. So, I'll give Grady a head start on redoing his "artifacts" list (which he hasn't yet moved over from his booch.com handbook site). :-)

8/25/10 Architectural Mechanisms

When we study animals, including humans, a distinction is made between anatomy (the consideration of the structure of living things, wikipedia) and physiology (the "science of the mechanical, physical, and biochemical functions of animals/humans in good health, their organs, and the cells of which they are composed", wikipedia).  For example, if we think of ambulation, we think of the interaction between various components, and we can narrow it down to a focus on the various joints and how those work, and how various components interact in coherent purposive mechanisms, and mechanisms in combination collaborate or interact to achieve ambulation. We can think of the knee in terms of it's purpose or goals, anatomy (the parts) and physiology (the function) -- that is, in terms of the knee as a mechanism.

That "what are the structures" versus "how it works" distinction is useful to make in architecture. The point that we emphasize in the Visual Architecting Process (VAP), is that we need to think about both the structures and the "how it works," holding both in creative suspension and iterating between various (as useful to us) views of structure and behavior. For the most part, design patterns, to me, are usefully documented descriptions of tried-and-true mechanism designs.

8/25/10 Requirements "Churn"

We often point to requirements churn as a major source of issues, even failure, in software. But isn't this just an artifact of our aberrant notions about "requirements"? We take desires, and goals, and constraints, and hopes, and frustrations, and so forth from (maybe) "representative" stakeholders, and munge these all together and think we have "captured" a set of requirements. But actually these are hypotheses and best guesses and negotiations and compromises based on gut feel and loudest voices and conversations on the golf course and at the coffee machine--not just one, but many, interacting best guesses and assertions (founded on who knows what assumptions). If we just recognize that these are hypotheses, in a good case, but just barely articulated hunches in the average case, then we see that they are highly subjective, accidental, mutable and emergent. Hence, we need to be more explicit about testing various alternative best guesses as quickly and cheaply as possible, moving around the space and tuning up our sense of what will be an exciting product for a big enough market to make good business sense. Then we orient our whole process towards designing the concept and its interactions with the environment--we design its purpose and its fit to purpose; we design (with varying degrees of freedom depending on the context) its fit to context by redesigning its context, etc. That is, design is an act of creation--of problem finding and solving--from the first seed of an idea through stages of maturation and evolution, and fresh upsets in expectation generating new opportunities to find and solve problems.

In other words, we have tended to take something that is inherently organic and messy, even chaotic, and act as though it is mechanistic and deterministic. The properties of complex systems emerge from the interactions--interactions with the context, and interactions among the parts. These aren't entirely knowable in advance. Worse, though--expectations and desires also emerge! This makes the development of new systems inherently wicked. Moreover, the evolution of complex systems tends to be wicked, because complexity means we don't have a complete handle on the system even before we attempt to evolve it.

So, yes, we do need to make development as predictable and well-organized as we can, without thwarting creativity. But we also need to have different expectations and measures for production lines than we have for system development.

And yes, we do need to state our goals, and become more and more clear about acceptable ranges of tolerance for system properties and refine and elaborate the core functionality, and all the good stuff of requirements definition. But we could stand to use a more innovation-age, less industrial-age, approach to requirements and our definition of churn and failure. We need to stimulate and embrace churn early on, fail fast, cheap and often, early on, so that we can find the differentiating value propositions (for business stakeholders, for customers, and for other key players in the value network) that will make the system a big success. If we fail to do this, we get requirements churn late in the process, and that is costly!

Unless the churn is coming from a new perturbation in the market, in which case we have to discover what new problems and opportunities and threats are presented to us.

8/25/10 Chaos and Dragons

Which leads me to chaos and dragons. Ok, so you know that Grady Booch collects dragons, right? What, you don't remember every word of his blog? Ok, I don't, yet surprising details strike and stay with me. Like he collects dragons and there's a (serpent-like) dragon (I think) behind Alistair Cockburn in the video of his reading of "The Hike." When the kids were little, Dana used to tell them an ongoing story about "Gregory (a goat) and the Dragon" (a story Dana made up as he went--we should have recorded his telling, because it was really good). Anyway, it seems like there is a dragon leaning at least among these three influencers in the software space.

As for me, because I have to get the Cutter Report done, naturally I find it absolutely imperative that I work at sloughing off layers of kid-crud that has accumulated from too many years of living in one place and working 10-14 hours a day 7 days a week -- well, save for bursts (that's a hat tip to Daniel's pointer to the book of that title) of play (being an intense person, I combine exercise, kid/husband/dog time, and play, into cycling by moonlight, kayaking outings, hilly forest runs, etc.). In other words, I'm facing chaos, and thinking about dragons.

Dragons? Well, dragons are intimately linked with chaos (and creation/creativity) in various Greek and Egyptian myths. For example:

Chaos (Greek χάος khaos) refers to the formless or void state preceding the creation of the universe or cosmos in creation myths, particularly Greek but also in related religions of the Ancient Near East. The motif of chaoskampf (German for struggle against chaos) is ubiquitous in these myths, depicting a battle of a culture hero deity with a chaos monster, often in the shape of a serpent or dragon. He is known as the god of darkness. -- wikipedia

Ok, so maybe I'm just gripped by my internal "it's of no consequence" demons, deflecting the chaoskampf I should be fighting intellectually into a physical chaoskampf. Since I wrestle to make our Executive Reports high in utility and aesthetically rich, it takes a lot of emotional risk-taking along with intellectual hard-work. Given the pattern that's emerging, it seems like I have to descend into despair, to emerge with a fighting, defiant spirit that allows me to wrestle these reports into existence. I thought I was done with that "creation out of chaos" phase with this paper, but the silence on Part One threw me back into uncertainty. I remind myself that this is Summer and the proportion of readers who rouse themselves to say something nice is very small, but still the silence has its impact. Yes, word has come back from diverse sources that our past Reports have been valuable. Look, I know full well that a paper on mechanism design, for example, would be more likely to get word-of-mouth referrals and so forth, but I think we have important lessons to share about the architect as culture shaper and leader. And I think the organic fractal strategy-architecture tandem is a crucial enabler for agility and innovation, so I thought that paper was important to write. Etc. Oh well.  

Well, if you do a good job of sharing your positive take-aways from The Art of Change: Fractal and Emergent (or Getting Past ‘But’: Finding Opportunity and Making It Happen) you'll be invited to review Part Two. :)

8/26/10 Oh my! Software Architects, we draw fire!

I was quite taken aback by the comments on the article titled "I'm an Architect" in Architect magazine. We have taken some heat from within the software industry for the software architecture label--which surprised us, since it predated us by a long shot. But reading the reaction within the building architect community, apparently there are folk out there who are downright upset at the use of the title "architect" in IT. And they have some pretty sharp words about software in general. Negative comments often come from those who are unhappy enough to overcome inertia, so I don't suppose every building architect feels as strongly. Still, I can see why they'd get a little hot under the collar at my need to qualify architect with building! Yet, isn't this all underscored by a key architectural point: context factors. In this context, I'm talking to software, system and enterprise architects (of various "flavors" or realms of authority and focus), so I need to qualify building architects accordingly.

In the building context, they have certification requirements they have to fulfill in order to use that title, while in our context we don't, but the history and demands of the fields are different. In our context, to become an architect, one has to have a very considerable experience building systems, and demonstrate design and leadership skills besides. And then we remain architects by a trial of peers--if developers think an architect's experience set is obsolete/irrelevant, they will set about undermining and overthrowing the architect. So the demands are stringent, though not uniform or standardized (various entities offer certification now, but it's not a requirement to bear the title).   

Ok, just so that we share the heat (smile), let's be sure to note that software isn't the only area where those who are concerned with system design are called architects. The wikipedia entry on hardware architects is especially interesting:

"The hardware systems architect or hardware architect is responsible for:

  • Interfacing with a systems architect or client stakeholders. It is extraordinarily rare nowadays for sufficiently large and/or complex hardware systems that require a hardware architect not to require substantial software and a systems architect. The hardware architect will therefore normally interface with a systems architect, rather than directly with user(s), sponsor(s), or other client stakeholders. However, in the absence of a systems architect, the hardware systems architect must be prepared to interface directly with the client stakeholders in order to determine their (evolving) needs to be realized in hardware. The hardware architect may also need to interface directly with a software architect or engineer(s), or with other Mechanical or Electrical Engineers.

  • Generating the highest level of hardware requirements, based on the user's needs and other constraints such as cost and schedule.

  • Ensuring that this set of high level requirements is consistent, complete, correct, and operationally defined.

  • Performing cost-benefit analyses to determine the best methods or approaches for meeting the hardware requirements; making maximum use of commercial off-the-shelf or already developed components.

  • Developing partitioning algorithms (and other processes) to allocate all present and foreseeable (hardware) requirements into discrete hardware partitions such that a minimum of communications is needed among partitions, and between the user and the system.

  • Partitioning large hardware systems into (successive layers of) subsystems and components each of which can be handled by a single hardware engineer or team of engineers.

  • Ensuring that a maximally robust hardware architecture is developed.

  • Generating a set of acceptance test requirements, together with the designers, test engineers, and the user, which determine that all of the high level hardware requirements have been met, especially for the computer-human-interface.

  • Generating products such as sketches, models, an early user's manual, and prototypes to keep the user and the engineers constantly up to date and in agreement on the system to be provided as it is evolving."

-- Hardware architect, wikipedia, as of 8/26/10

The bottom line, I think, is that these are heart-rending times when people are in serious pain, and we need to fix the economy so we can hire architects to green our buildings in a mass wave of reducing our environmental footprint! And to fix our economy, we need to focus engineering ingenuity on creating environmentally sustainable products we can buy in good conscience! Regrooving workplaces and homes to reduce our impact on this planet will be a huge undertaking, with jobs for all kinds of architects, engineers, and everyone else!

Even software ninjas!

8/27/10 Software Ninjas

The software hero who can rescue projects with great technical feats has always had, and no doubt will continue to have, a strong place in our software culture because they get things done, and what we actually build has a way of shaping expectation and reality, so the successes are self-fulfilling and self-reinforcing.

The technical challenges we have to deal with in software will only become more intense, and the superbly capable technical specialist who can address the class of truly gnarly challenges will always be in demand. The challenges will be different, but there will be challenges! We expect and demand more and more of our systems. We keep pushing the frontiers of capabilities--of our systems, and the people who build them.

So heroes and technical specialists are important resources that we ought to treasure, nurture, reward. And this might create some confusion for managers, who are fundamentally responsible for results in short timeframes.

Besides, it simplifies things to take someone's good idea, and build it--build it fast with the best fast builder you can get, so you can let the market give you feedback and you can speed through cycles of improving the system before competitors can get a system out of the chute.

But if Herbert Simon was right, and design is the act of making things more the way we want them to be, then figuring out how we would like them to be enters the design frame. Finding out by putting built systems in front of users is a pretty costly process of Darwinian evolution through market selection! Yeah, it is always the ultimate test (obviously). But if you take your first idea of the day, and give it 15 minutes of letting alternative ideas rip, do you come up with a better idea, or ideas that show promise of leading to better ideas?

We can over-complicate things and try to give too many people a say, and churn in "analysis-paralysis" seeking better and better ideas and getting so many ideas on the table we can never reach agreement and so forth. We can set ourselves up to fail by doing too little, or too much.

8/28/10 Re"Tweet"

If you followed my visualization tweet stream, you'd see a pointer to a great presentation on Visualization in Software Product Lines by Thiago Fernandes of the RISE (Reuse in Software Engineering) project in Brazil.

Some people seem to think that "reuse is dead." Reuse will never be dead. Our antibodies towards the word may be ferocious, and we may prefer to say "use" or some new word with which to make the practice of building with existing stuff more sexy. We keep raising the platform of software development, moving more into "middleware" and frameworks, which we "use" (or reuse). And when we are creating product (or service) variations, we are going to clone and grow (sloppy reuse) or more systematically reuse (or use existing) software elements. 

This presentation also deals with visualization in software product lines: Virtual Separation of Concerns, by Christian Kästner

I also looked through several presentations by Michele Lanza and by his PhD student Richard Wettel (The Visual Terminator, Of Code and Change: Beautiful Software, Visual Exploration of Large-Scale System Evolution, Visually Localizing Design Problems with Disharmony Maps, Visual Software Analysis, Software Evolution, etc.). There is overlap among these presentations, but even that is interesting because it provides an interesting view of the evolution of their research as well as the evolution of the framing or pitch for software visualization. I love this slide from Michele Lanza's presentation titled Seeing Software:

Source: Seeing Software presentation  by Micehle Lanza http://www.slideshare.net/michele.lanza/seeing-software

Now, it'd be cool to see, instead of just connections, the dynamic "flight path" unfolding (video). And it could get pretty (and revealing) if lines were color-coded for the originating package (back to static structure). Etc. As for city evolution, it'd be neat to see that applied across a product line. Etc. Take any one idea, and there are lots of places to push at it.

As information visualization goes, Justin Donaldson and Paul Lamere's Using Visualization for Music Discovery slideset has lots of interesting, even stunning, examples, and their discussion of visualization has much that applies to any visualization space (some of it is taken from Colin Ware's Visual Thinking For Design book).  This visual map of visualization approaches in music is neat:

Source: Using Visualizations for Music Discovery, by Justin Donaldson and Paul Lamere

Source: Using Visualizations for Music Discovery, by Justin Donaldson and Paul Lamere

I know, I didn't embed the presentation -- I simply wanted to direct attention at a specific slide, keeping the slide number reference visible so that I can go back to it. By all means look through all 266 slides, as it is quite interesting to see what creative work is being done in information visualization applied to music discovery. :-)  

If there are visualizations that you are using to help you get/keep a handle on your software (code base), please let me know what you're using and how you find it valuable. I don't have access to every IDE, for example. Besides finding out what is out there, it is helpful to know to what extent.

8/28/10 Motivated!

Before closing down for the night, I stopped by Jeff Atwood's blog and, on his insistence (if I didn't follow well, what kind of example would I be setting?), I watched Dan Pink's and RSA Animate's ☼Drive: The Surprising Truth About What Motivates Us. It is really well done, and makes an important point! Since architects are setting the team context that allows for empowerment and self-organizing, self-directed work to take place, this is a useful, and fun, use of ~11 minutes. It also motivates the involvement of people in the creation of the meaning and purpose of their work. And, again, it is a great visualization.

8/29: So I stood -- I was closing down, remember -- sucked by the youtube sidebar into watching "Smile or Die" and again the visualization was great, although the text seemed to be playing for popularity in these upset times, and the logic was inconsistent/flawed/sensationalist. But the visualization is superb!

The use of visual metaphor in the drawings is worth attention all by itself. Remember, it is very useful to develop a toolkit of visual icons that you can practice sketching and do on the fly to spice up what you are saying, so that you show with pictures not only words. But the visual metaphors imply words, so carry a package of meaning. Blah, blah rhetoric. Advice you didn't ask for. Rats! Oh right. Advice to myself. Alright then, I can live with that!

Ok, I'm psyched. Let me at those sketches.

Or not.

Motivation is such a tricksy thing! Well, I love lunchbreathe's Maslow's Hierarchy as Scorecard cartoon sequence.  Let me just say, I'm with the dog. 

Oh, the dog!  Gotta run!

8/29/10 Sketches

Here are some sketches (from early 2009) contrasting a start-up with a "mature" organization. I apparently had decided they weren't fit for public display. Silly me!

Start-up: customer understanding and technology understanding are joined at the hipOrganizational chasm between functionally divided disciplines

The next image in that set is the architect who functions despite the dysfunctional context, by ignoring the hierarchy with its communication gates.

Flatlander: no respect for hierarchy

That architect is, though, vulnerable to being whack-a-moled:

whack a mole with architects

Yes, I've used the last of those before. Actually, it was from a different sketch set, but it completes the vignette. :-)

Here's another that belongs:

kick "but"

Yep. Kick "but." Just do it. The talk thing. The draw people in thing. The do thing.

Ok, before you think that narcissism made off with my appropriateness-meter, please bear in mind that this is a very quiet backwaters place where I trace my thinking. And if I don't use those sketches, and the story they tell, they will be lost in the accumulating stack of sketched notebooks.

8/29/10 The Art of Small Talk

(Dana relayed:) Bucky Fuller said "Ownership is onerous."  When I lift my head from work and look the accumulation chaos dragon in the face, I so get that!

As for pithy statements: there is a challenge on the CAEAP LinkedIn group to express the purpose of EA in 160 characters. This SMS-chunked challenge has bounced around on Twitter, etc., so I've seen various stabs at a concise statement of what EA is. Anyway, given the terminology elucidated in The Art of Change, I took a swing at it:

Leading the fractal translation of business intent into business capabilities, and rationalizing emergent capabilities to improve design integrity.

It's not entirely satisfactory, even as a synopsis of The Art of Change: Fractal and Emergent, but I think we need to express that combination of top-down and bottom-up that we go after with "fractal and emergent."  EA, like (top-level) business strategy, deals with the "umbrella over all umbrellas" enterprise scope, but it is not all about driving purposive action but also about reflecting on and aligning and improving based on what is done and learned by those empowered to act and react responsively to opportunity and challenge at more narrow decision scopes.

Is that an important view, and does The Art of Change articulate the view, and its importance, in a compelling way? If you think not, that was rhetorical. Motivation is such a tricksy thing! E. T. C.   Software Architecture Workshop on the walls!

8/30/10 Reminder: Software Architecture Workshop in Europe

There are still some seats open in the Software Architecture Workshop to be taught by Dana Bredemeyer (in English) in Düsseldorf, Germany, on September 13-16, 2010 (hosted by CodeCentric). Please pass the word on. :-)

You can think of this as learning how to construct a very visual narrative for your system. One that stands up to the push and pull of business demands and the need for design excellence (where it matters). Iterative. Incremental. Evolutionary. Participatory and concurrent. E. T. C.  The usual drum roll.

8/30/10 Shattered Dreams

Dana stopped in to get bread at the local bakery, and there was a taster basket of "dream bar" bits on the counter. He tried one and the person at the cash register said "They're shattered dreams." Humor is all around us!  I had to do a visual, because it so fits the tenor of our times:

Must  . improve . sketching . and . handwriting . skills . Must . improve .  ... Or not.

Ryan can draw perspective better than I, but he and I both draw people as stick figures. Still, mine are boxier. Nah nah.

(Nah nah? Oh, I do miss Darth-Don. Wicked suit!)

8/30/10 Random: On The Power of Visuals

When I told Dana about this xkcd, he said we really ought to keep some copies in the glove compartment of the car. :-)  

Any qualms* I had about the (NSFW) Lady Java promo video for the JavaZone 2010 conference, were assuaged when I saw the Buttercup Festival Aviation Lechery cartoon and I realized our field sorely needs a lechery image boost. :-) 

* along the lines of: is it right to use a "sex sells" (and NSFW adult imagery) to promote a tech conference, and, given that women are in a minority, does that place women at the conference under an uncomfortable "blinking arrow"?  The comments on Lady Java on YouTube and "If Historical Events had Facebook Statuses" have much the same spread from love to vitriol, and my concerns are definitely moderated by the intelligent and bawdy humor of the video (and the also NSFW  Java 4Ever companion promo piece). Do we want to keep trending towards supporting content in tech conferences that we would label NSFW, and how do we keep it out, if the promo is NSFW? But it is funny and well done! What a quandary! 

On a lighter note:

Did you catch today's xkcd, or were you waiting to see if I liked it? Anyhow, don't you just feel like that sometimes? No? Um. So sorry. I didn't realize you were reading here. Please, excuse me. I have to go now.

[This is so embarrassing.]

* I love the video--the wit and parody is superb. Promoting the field as one that has a sense of humor and a healthy willingness to laugh at itself is wonderful! But if it shades into placing women "under a blinking arrow" at conferences or further entrenching the image that the field is a realm dominated by tech-machismo, then I have qualms. On the assumption that everyone gets that "sw tech has gone pop" is multi-layered, great! Software is sexy is fine, as long as it doesn't mean women get treated as sub-ordinate sex objects. We might want to balance the whole thing our with a green social interest promo piece, just to really be even-handed with the appeal... A "nerds saving the world" kind of thing.  

8/31/10 Procrastination

I love the procrastination sequence on phdcomics (untitled procrastination, Your "To Do" List, untitled Just say "No"). Why am I looking at phdcomics? I'm working on that visualization presentation, really I am. Right now it is: visualization and quality. Glancing through Tom Zimmerman's presentation (I love the cover slide!) I saw this cartoon: strip 1 and strip 2. Ok, so that is pretty much how I write those Cutter papers (wink), so I went to the source (I hadn't stopped by phdcomics in a long time; I really only troll cartoon sites on occasion, all link evidence to the contrary, of course) and yep, stumbled on the procrastination sequence which is, yes, pretty much where I'm at with the Cutter paper. Well, there's the small matter of working with Dana on his conference presentation, and ... well clients would (emphatically) rather I didn't say.          

Grady Booch pointed me us to this superb "modern science map" visualization, and from there I landed on yet another (great) periodic table visualization... And, exploring a bit further (come on, a blog titled "Science, Reason and Critical Thinking: A Blog in Words and Pictures" and I'm not to explore further? Garr!), it occurs to me that the comparetheideology.com post pairs well with If Historical Events had Facebook Statuses -- so steer clear of the second if you didn't like the first. :-) But, oh dear, critical thinking can become pretty muddied when it takes on The Church...

Back to visualizing bugs with me!

8/31/10 Visualization

I came across Stanford's Spatial History Project and these lines from their introduction to their Visualization Gallery struck a chord:

"Visualization of historical data in time and space illuminates patterns of movement and transformation in the past. We are experimenting with visualization as a tool to develop new arguments (and new questions) about historical processes and understandings of major historical events."  -- Spatial History Project, Stanford

A chord? Well, isn't that a neat way of putting it? We use software visualization to understand the system, but also to help us ask new questions about the system! New questions, new lines of inquiry, new tentative reasoning, are so key to developing new insights. And new insights are neat 'cos they produce a eureka flush in the brain and they lead to, like, cleaner, simpler systems... (kid-interrupted night last night; my sleep-deprived brain is on E)

8/31/10 Changing the Life of a Teacher

I really enjoyed Sal Khan's GEL 2010 talk sharing his introspections on why the Khan Academy works so well (if you don't know about the Kahn Academy, you owe it to your kids to check it out!). The last 4 minutes especially struck me. Why? Because changing the life of a student (and being told about it) changed the life of the teacher. Now people are talking Nobel prize! And I agree! Give him a clean sweep of all the Nobels!! He will deserve them. ;-)  

Sigh. In my case, ... the cold shoulder of silence...  oh well, I have only to remind myself that this is where I teach myself -- part educo (draw forth from within) and part joyful, bliss-following, awe-struck* exploration... thank goodness I have a ruth to listen to! And thank goodness you don't have to!!!

That's a cheery note on which to end the month! It's a good thing this page will be wiped clean for a fresh start tomorrow! :-) 

* borrowing terms from our good Mr. Booch

[Oh, I should say, client work and the activity on the Bredemeyer site and the volume and international diversity of mailing list sign-ups and, and, and, all is very rewarding and inspiring. So the educo that is done here, when chunked in small nuggets other places, gets a warm response. :-) ]

Ta Ta August. It's been fun. :-)

 

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! Bring value, and 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 could you untangle it?

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. I 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 © 2010 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: August 1, 2010
Last Modified: December 01, 2011