A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

July 2010

07/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 iteration, refactoring and documenting decisions), or it may be a characteristic or skill that is useful to develop (like humor or influence 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. Topics from this month are listed below the links to the archive, and the Blogroll follows.

07/02/10 The Art of Change: Fractal and Emergent

The Art of Change: Fractal and Emergent is at last complete, and The Art of Change: To Lead is To See, To Frame, To Draw is back on my "discretionary time" priority stack. Hopefully you'll read Part One: Fractal and Emergent (the what and the why) and be eager to read Part Two: To Lead is To See, To Frame, To Draw (the how). Naturally that will also go through review/improvement cycles, so if you are interested in getting to read the report before everyone else, offer to review it! Grin.

 Wordle of The Art of Change: Fractal and Emergent  (top 20 words)

Now, I should say that emergent is what we get anyway and easily. Right? We're always responding to, adapting, adjusting on the fly, inventing in the small, seeing, and shaping, within our field of influence. Business strategy and its tandem architecture creates coherence of purpose and concert among the many socio-technical systems, the many smaller pools of action and influence, within an organization, so that bigger, more ambitious, impactful things get done. While embracing emergence or extemporaneous dynamic responsiveness, we also note that achieving an ambitious vision takes intentional focus on making what is impossible or very unlikely through sheer accident, and aligning inspired creative, inventive thought and action so that many contributions of mind, will and hands build that vision. no strategy...   we are proud to say we have a shoot first and aim after culture...

Fractal strategy and tandem architecture are not new--we have just borrowed Bezos' image and put words to what is done, varyingly, in organizations. The important thing about creating this image though, is that it gives us a way to have the conversation about the relationship between strategy and architecture. Why? Because this is done varyingly in organizations--even within one organization, there is inconsistent understanding of the role of strategy, let alone architecture!

In some cases, strategy is viewed as a "bad word"--there is "no strategy," and that is treated as a point of cultural pride. A point of cultural pride. Hmmmm, that sounds like identity, which is a key part of strategy.  So strategy in the organization is fractal, with an independent "cowboy" (shoot first and aim after) culture set as the unifier at the corporate level, and other elements of strategy pushed out to the business elements. But as soon as that company wants to achieve something more coherent across its businesses, it finds itself needing to work strategically and architecturally to create a shared intent and the relationship platform for enabling that coherence. So, whether "dynamic, organic, fractal strategy" enters their parlance, allowing them to explicitly talk about intentional and emergent strategy or not, they have to get more intentional if they want to do those bigger things that require concert to make them more the way they would like them to be (Herbert Simon's wonderful way of defining and motivating design).  

Dynamic? Allowing for learning and responsiveness. Organic? Embracing empowerment and emergence. Fractal? Set at different loci in the organization. Strategy: read the paper. Wink. And tandem architecture? Oh right, now we're getting into a number of papers, websites, ... Smile. But the paper is a place to start. I do hope you'll want to read it. And recommend it. We should have the URL after the long weekend. Grin. [7/14: Here it is: http://www.cutter.com/offers/artofchange.html]

A couple of reviewers mentioned that the report is "advanced reading" for an entry-level architect. I hope not. I hope that it persuades managers and architects that there is an important bridge between architecture and strategy, and that bridge doesn't have its foundation entirely in the business side, nor entirely in the technical side--but rather in a partnership where strategy and architecture work together collaboratively. That is, they inform and are informed by each other, enhance and are enhanced by, lead and are led by each other. And I hope that the paper unfolds the salient topics in an accessible manner--accessible to both managers and to architects, to motivate and enable that bridge-building. Enable, because the most important thing to ability is the conception of the thing being worth doing! ("Most important" is strongly put, and provokes a question of accuracy, but my sense is that it is right... I'll have to think more about it though. It seems right though also not complete, like necessary but not sufficient... and while not sufficient, it creates the drive to assemble all the sufficiencies... Look, that is what it is like to be in my head. If you don't like it, you don't have to read this. But I have to live in this head! You could have some compassion! Grin.)   Strategy and architecture in tandem

I drew a cartoonish sketch of the strategist and archman riding tandem, but I really wanted to add another where the tandem with the architect out front steering wins the race. I didn't*, because races are dynamic and unpredictable, and sometimes technology-led innovation wins, and sometimes customer-led innovation wins, etc. And this can happen in the same industries so there is no magic recipe. Magic. Incredible connections. But no formulaic recipe. No algorithm. Not even a pattern we can mechanically stamp out.

By the way, on our Hobie tandem kayak, steering is done by the person in the back. Perhaps that is a better image. :-)  But kayaking tandem sure reminds me of the importance of persuasion and influence--if I sit in the front with the camera to catch the bald eagles and herons--and deer swimming across the lake (who knew deer did that? not I!) then I have to communicate and persuade the person at the rudder to go where I want to go!

* Ok, ok, I didn't because I am time-constrained--meaning lazy... uh, I mean busy... :-)

ps. don't you like the synchrony between the strategist and Archman in the sketch? I'm so often amazed by what the "hand" knows that the conscious mind wasn't explicitly working on...  I wish I could draw better, but it's still interesting to see what comes out when I (try to) sketch. And that's part of what is so important about drawing and visual modeling, isn't it? The something new that we see in the relationships that visualization makes apparent. This video of Milton Glaser talking about thinking while drawing (by way of David Sibbet's blog) is salient. Dana says he has read/we have the book Glaser refers to--The Hand. Dana just hadn't connected it with the visualization dive I've been on, but says it is quite interesting.

pps. I love the Wordle of the paper. It was Ryan's suggestion--actually, he suggested that instead of writing the Executive Summary, I just create a Wordle image. I liked that idea--a lot! Alas, I wasn't able to sell it. Grin. Anyway, I love that it looks like an arrow, and strategy aligns and points in a common direction, but it's not a perfect arrow, and that comes from emergence. But because it is not perfect, it also looks like a tree--trees are organic life images, so that is neat. And the trunk of the tree, on which all else rests, is business, and that is a useful reminder for us technologists. And design is the load-bearing central point of the tree and the arrow. Wordles are great, because our meaning-loving minds can find some, even when it's randomly generated! Grin.  Still, if you look at the words that pop out as the top words in the paper, doesn't that just make you want to read it? No? Oh dear. Really? You're not intrigued by "strategy, value, capabilities, architecture, delight"? Or "integrity, architects, design"? Or "system, change, architecture"?

7/2/10 Prescience and Intentionality


the surprise that undoes!7/2/10 On Failure

System faults and failures--some examples that made the news

Classic examples of system failures

On system failure


Research papers

On project failure

Learning from failure

Funny Fail

From my journal

By analogy

Investigate risk and consequence, and find someone to play devil's advocate--and be your own devil's advocate to find weaknessesWhat to do


You never learn by doing something right. ’cause you already know how to do it. You only learn from making mistakes and correcting them” -- Russel Ackoff

"The nicest thing about not planning is that failure comes as a complete surprise and is not preceded by a period of worry and depression." - Sir John Harvey-Jones 

"Not only are a system’s desired operating modes influenced by its architecture, but so are some of its failure modes. Thus an architecture that permits only one path between elements may fail if a leg of any path breaks. All of a tree below a broken node is isolated from the rest of the tree."

-- Edward Crawley, Olivier de Weck, Steven Eppinger, Christopher Magee, Joel Moses, Warren Seering, Joel Schindall, David Wallace and Daniel Whitney, "The Influence of Architecture in Engineering Systems,"
MIT esd, March 2004

"Success breeds complacency. Complacency breeds failure. Only the paranoid survive." -- Andrew Grove

“If automobiles had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside” -- Robert Cringely

7/5/10: Ok, so this is spooky--on Friday July 2, I returned to the failure/risk topic of June 29--And Failure. I didn't think to look in on xkcd until tonight, but did you see Friday's xkcd? What we are paying attention to shapes what we perceive and pay attention to, and all kinds of fallacies in human reasoning are brought up with this one! Like, how often our deep dive is into whatever is top of mind... tunneling deep is something we geeks like to do; it makes us feel "safe" to get our analytical (left brain) juices flowing... it is where education tends to focus, and it is what enables us to push the frontiers of science and the cusp of what our systems can do. We want to get to our comfort zone, beyond all the fuzzy uncertainty brought about largely because there are areas that are not our purview or decision space, so we tunnel as quickly as we can past the "breadth" space that overlaps with other stakeholders who, frankly, slow things down and complicate them with messy communication!  And it is why one of our biggest areas of proneness to failure is "failure of the imagination'... failures in direction, and failures in anticipating and prioritizing risk.

Spooky? Did you get it? The brain wants to makes sense of things. Our drive to assign cause to effect, to provide an explanation, etc. is useful, but highly flawed. Here are some notes from my reading of The Thinker's Toolkit that I used in my SATURN tutorial:

  • We instinctively see the world in terms of patterns: Situations, Relationships, Sequence of events, Categories
  • We look for cause and effect relationships: “Humans are pattern seeking animals. We must find cause and meaning in all events… everything must fit, must have a purpose and, in the strongest version, must be for the best.” –Stephen Jay Gould

This need can be satisfied by chance, coincidence, illusion, etc. (i.e., even when there is no relationship). It is the false perception of cause and effect that enables magicians to trick us! 

Slide from my SATURN tutorial, referencing The Thinker's Toolkit

7/2/10 Where Technology is Going

7/2/10 Did You get It?

Ok, so I put a placeholder for a post on Prescience and Intentionality in this journal earlier today. Looking at it now, it is too funny to change! I suppose you'd have to be prescient to get my intent! Grin.play out multiple future's in our mind's eye--including futures where we explore risk and consequence

Any guesses?

7/3/10 Failures of Imagination, or just Optimism

When I first read "most cases of failure... have been in two categories: imagination and process" (Grady Booch) what I thought most about was failures in direction--doing the wrong thing because we simply didn't project ourselves in various ways--into the future when the system is in place, but other trends and forces have played out too; into use contexts, to empathetically grok what users care most about, or to assess *ilities, etc., etc.  I'm not saying all of this should be done in our imagination--but if the system doesn't exist, it has to be imagined! So we imagine, and prototype, and build out iteratively, to get a more and more clear sense of where value and "delight" lie.

But of course we also have to imagine what could go wrong. And creating a system, especially an ambitious system, is such an exercise in optimism that we perhaps are disinclined to think through all the ways in which it might fail. I hadn't thought of this facet of the failure problem before. Blindness to risk and consequence yes. But optimism, no.

When it comes to the 4th of July, my imagination goes into overdrive, to compensate for what my pyro-loving family are way, way too optimistic about! It stresses me out major, but I can still enjoy how pretty it is. All the while thinking about how things are going to change, as we become more conscious of climate change and the impact of blowing up a bunch of fireworks that got transported all the way from China! Every year I say "never again." Then Mythbuster-fan, pyro-loving master Ryan delights his way back into "just a few" which I won't shop for, so without me there to wet-blanket the affair... becomes another mom-stress-out.


7/3/10 Emergence and Failures of Discipline

Fimo turtle with stained glass effectThe image is a little piece of our home, and it is for me what emergence--with the lightest touch of intentionality--is all about. The table is from South Africa, the wooden bowl and fruit is a Dennis Hales piece (UK), the ceramic and brass lamp is by Stuart Gray (MI), and the glass bowl is from a gallery in Half Moon Bay, CA. When we bought the pieces (over the years), each was chosen on its own independent merit, not thinking about where it would find a home. What unifies, is a coherent aesthetic. Each such space has its own quality, each quite different. And with the wash of time, each amasses its odd appendages. Now, that particular table also has a fish picture by Ryan. It is lovely, and I want to frame it--have wanted to for a few years. And while it awaits that destiny, it shares that table, along with a fimo turtle I made (my third try at a fimo creature, so I was quite surprised by it). And a glass ball my sister gave Sara when she was little, because it is magical and it's something no-one would ever think to give a little girl--except my sister, who has her own kind of magic. And so it goes.  All of these pieces cohere sweetly together, yet there is a sense that it is just too much.  

Adding complexity. Innocuous at first. Then at some point, it's just too much, but what goes? Not the turtle! Grin. Some wonderful art, some family legacy, and it is very "us" and not nearly so pristinely perfect as it was before the "droppings" of family sentimentality added too much muchness to it.  

The stained glass effect on the turtle picks up the pattern of the glass bowl, its blues and those of Ryan's fish complement the silvers of the Hales fruit and bowl. But they're schlocky companions to the fine pieces of art we've picked up here and there on our travels over the spread of years. Ryan's fish etched on painted background; created in 2007

So we get to failures of discipline. And the line that is hard to draw. Especially when sentiment and feeling are involved.

Of course, we never fall foul of this in software development, do we?

7/4/10 Happy Fourth of July!

Happy Independence Day if you live in the USA. And happy 4th of July everywhere!

7/4/10 Risks and Consequences ... and Checklists

The architect, as the "ultimate design authority" responsible for design integrity, has to think about the ways the system could fail, and because that would be a disabling space to get mired in, decide (and bring to the business partners for attention and resources) which to prevent, which to mitigate, which to transfer, which to investigate further or to optimistically ignore, etc. And then we get into the unknown unknowns. But we also get into practices for sussing out the imaginable unknowns. And then there's the usual suspects. Like power failures.

Checklists are good. I'm all for them. They raise our platform of practice, and advance what we can take on. But judgment is essential, and judgment takes time. Yes, time and experience to develop, but I mean time on the schedule! Every single decision we make explicitly takes time, so we make a huge number of them implicitly. What we ignore is an implicit set of decisions. We have to do that to cope. Time and other resources are limited. Competition creates an inexorable onward march. 

"It’s all a question of cost versus risk."

-- Keith Armstrong, Toyota "Sticking Pedals" Recall a Smokescreen, Feb 28, 2010

So, checklists. Patterns and practices. Take availability. When we checklist the various ways things can and have failed, that directs our attention. Intuit based scale demands on estimates given past filings and estimates of switching to electronic filing, and still seriously underestimated capacity for this year's tax filing deadline. There is a lot of room for forecasting, instrumentation and analytics when it comes to monitoring and foreseeing, so we can respond to known risks. But there are still surprises. And for risks of serious consequence, there's the response and containment and recovery plans. The plans for containment given knock-on effects. Imagining the outward ripple of problems interacting with problems, until a failure of consequence occurs. What could Intuit have done? What should they have done? I can imagine a few things. Yes! Imagine! Project. "Be" in that situation beforehand, and think it through.

Again, judgment is called for. And that is my concern about checklists and architecture document templates and the like. They're good, useful. And we cannot let them do the driving for us. There are too many interdependencies, context dependencies, matters of blink intuition and areas where we needs must invest in serious analytical pursuit to assess and ameliorate or plan to contain and recover from. Or not. So we can't give good sense over to a checklist, and hold ours in abeyance, thinking that the job is done for us. We have to be ever watchful for the difference that makes a difference. It is human to file late. And it is human to defer thinking about what happens when everyone defers filing until the last minute. Then it is human to point fingers of blame--away from ourselves. And so on. Well, we're designing for humans! We need to take that into account.

That caveat indicated, checklists rock. Please give me pointers to checklists you have found useful, and I'll list/categorize and share them. Btw, I find that the qualities requirements space has much that applies nicely--for example, availability requirements speak to characterizing demand patterns and forecasting, and not meeting those is a risk of failure, so it is the flip side of the requirements coin. Of course, our checklists are even more helpful when they point to strategies and even mechanisms (and design patterns that document proven approaches to designing those mechanisms) we can design into our systems to address the challenge (and associated risk that we fail to do so). In the security area, 2010 CWE/SANS Top 25 Most Dangerous Software Errors has both the errors that can lead to software vulnerabilities/failures/flaws/holes/breeches/whatever and the "monster mitigations" to eliminate or reduce the severity of the vulnerability.

Here's a couple of links I've pointed to in the past;

Some of the success for Peace Shield II was attributed as follows:

”We had a program manager with enough vision to say, ’What things can we do to abate our risks?’ and then immediately got out the checkbook to fund the abatement plans.”

-- Jeffrey D. Vermeer  as quoted by Robert Charette in Understanding Failure by Examining Success, Nov 2008

On the importance of checklists:

Sara, letting go to brush leaves out of her hair, fell off the swing. She got up, dusted herself off and said: 'Note to self: don't brush off leaves while on swing." I thought "How can a child smart enough to say that, be stupid enough to just do that?"

Not imagining our way/using prefrontal cortex extrapolation to avert the mistake in the first place is bad enough; not learning from  mistakes we already made is worse. We want checklists and other accumulated wisdom in our field and our practice to guide us away from repeating mistooks.

The safety argument fallacy taxonomy in this paper is interesting: Framing analysis of software failures with safety cases (.pdf), by William Greenwell and John Knight.

I also write at:

- Resources for Software Architects

- Architecture Action Guide

- Trace In the Sand Blog


- Other Interests

- Introducing Archman



- Links to tools and other resources


Trace in the Sand
Architecture Journal


Journal Archive

- Journal Map


- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- Current


- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December


- January

- February
- March

- April

- May

- June

- July

- August

- September

- October

- November
- December

- January
- February
- March
- April

- May
- June
- July
- October
- December


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

- September
- October
- November

- December

- March

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

- October
- November
- December

July Topics

- The Art of Change

- On Failure

- Where Technology is Going

- Failures of Imagination

- Failures of Discipline

- Risks, Consequences, Checklists

- Unintended Effects

- Business Model Canvas

- eReaders

- Fractals

- That Picture IT

- Iterative Development

- Leaders

- Visualizing--Scary, Good, Trees

- Thing so Fragile

- Architecture Decisions

- VAP =d= Agile Architecting

- Visualization and Architecture Governance

- Design Rulez

- Kiva

- Opportunity in Undelight

- Directions for Art of Change

- Late is Better than Dead

- Software Architecture Visualization

- What's Worse?

- Leadership Moment

- On the Education of the Architect

- Art of Change Free Download

- Believe in Others

- Apple Embarrassed

- Framing Forces and Trends

- Re-Imagine This

- Visual - Misc.

- Innovation -- Misc.

- I Want One!

- Exposing the Invisible

- MacPaint Source

- NDepend

- Code Metrics and Architecture

- Details that Matter

- Weaving Ruth

- Upcoming Workshops

- Coupling and Cohesion, Modularity and More

- Design Thinking

- Visioning

- Interesting Numbers

- Hard to Catch

- Adding "With" to the 6 Interrogatives

- Window on History

- Innovation and Creativity

- For Kindred Seekers

- Luminaries

- Architecture Principles

- Software Visualization

- Good Design and Code Value

- Feedback

Chief Architects

- Charlie Alfred

- Rob Daigneau

- Donald Ferguson

- Thomas Lee

- Brad Meyer

Chief Scientists

- Grady Booch

- Martin Fowler

Enterprise Architects

- Todd Biske

- Adrian Campbell

- Leo de Sousa

- Tom Graves

- Paul Homan

- James Hooper

- Alan Inglis

- Nick Malik

- Jim Parnitzke

- Serge Thorn

- Tim Westbrock

Architects and Architecture

- "Doc" Andersen

- Simon Brown

- Udi Dahan

- Louis Dietvorst

- Kevin Francis

- Sam Gentile

- Adrian Grigoriu

- Simon Guest

- Todd Hoff

- Steve Jones

- Sjaak Laan

- Dave Linthicum

- Anna Liu

- Ruth Malan

- Chirag Mehta

- Gabriel Morgan

- Robert Morschel

- Dan Pritchett

- Chris Potts

- Arnon Rotem-Gal-Oz

- Shaji Sethu

- Leo Shuster

- Collin Smith

- Brian Sondergaard

- Michael Stahl

- Daniel Stroe

- Jack van Hoof

- Steve Vinoski

- Mike Walker

- Rodney Willis

- Brian Zimmer

Architect Professional Organizations




Agile and Lean

- Scott Ambler

- Elizabeth Keogh

- NOOP.nl

- hackerchickblog

Software Reuse

- Vijay Narayanan

Other Software Thought Leaders

- Jeff Atwood

- Scott Berkun

- Alistair Cockburn

- CapGeminini's CTOblog

- Joel Spolosky

CTOs and CIOs

- Rebecca Parsons

- Werner Vogels (Amazon)

CEOs (Tech)

- Jonathan Schwartz (Sun)

CEOs (Web 2.0)

- Don MacAskill (SmugMug)

Innovate/Tech Watch

- Barry Briggs

- Tim Brown (IDEO)

- BoingBoing

- Gizmodo

- Dion Hinchcliffe

- Oren Hurvitz

- Diego Rodriguez

- slashdot

- smoothspan

- The Tech Chronicles

- Wired's monkey_bites


Social Networking/Web 2.0+ Watch

- bokardo.com

- Mashable


Visual Thinking

- Dan Roam

- David Sibbet (The Grove)


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

7/4/10 Risks and Consequences ... and Unintended Effects

When I started the post above, I intended to write about unintended effects, knock-on effects, the myriad interactions, some foreseeable, many not, that make systems come undone. But when I grabbed hold of the tail of the idea as it flew by, and started to pull at it, it morphed into a different beastie... or post.  Terat!

Humans achieve the amazing! And it is amazing that more doesn't go wrong!  But for Toyota, troubles kept coming in:

Back in 2006, there were various promises from Toyota, including this:

"Moreover, the company has said that it will be more open in its disclosure of quality problems to ensure that the results of its actions are transparent to the company as well as the public at large."

-- Robert Charette, The Role of Scared Values in Managing Risk, The Cutter Edge, September 2006

Of course, there's always another perspective:

Risk, as with truth, is often hard to ferret out. Still, Toyota apparently thinks there are real issues:

And let's face it, there's a lot of ☼shift going on in cars these days, and much of it is going to electronics and software, leading to complex interactions:   

These complex interactions include interactions with humans. And interactions with stuff humans make. Uh oh. Well, there's a bunch of really interesting complex systems research going on at MIT in the Aero/Astro SERL Program.

Interesting references:

Just how many parts?

"The most elaborate mechanical watches are called très compliqué. They are, as their French name implies, complicated. A Star Caliber Patek Phillipe has 103 pieces. A Boeing 747-400 has, excluding fasteners, 3x106 parts. In complicated systems parts have to work in unison to accomplish a function."

-- About Complex Systems, Nothwestern NICO

A grand horological complication! Mechanical poetry indeed!

Unintended effects. Unintended directions. Interactions. Some predictable, some not.

7/5/10 Business Model Canvas

7/5/10 Other Interesting Links

7/5/10 eReaders

Well, well--nudging ever closer to what I want!

This infographic on iPad's competitors is interesting. But isn't it missing something... When I think about it, I realize a key ecosystem shaper is iTunes--we got locked in to iTunes with the iPod, and now any (sub)platform (iTouch to add apps/games and movies, iPhone to add phone, iPad to add e-Reader, etc.) in the family has a distinct edge over the competition because our all-important listening lives migrate with us to that platform. Lock-in is a big deal, and Amazon was smart to make Kindle reading possible on other devices, not just the Kindle. It is interesting to see that Barnes and Noble's nook eReader also has a free download version for iPad/iPhone/Blackberry/PC/Mac... If we are going to move our reading off dead trees, any forward-looking bookstore wants us to get locked-in to their e-books, and being flexible about who sells us the hardware platform to do that, seems wise at this juncture. The e-media market already has legacy to deal with, and iTunes got out to a leadership position early in the legacy lock-in game!

This is all very interesting, because this past decade ushered in a transformative moment for the music, video and book industries, heralding the movement of personal libraries onto devices. Less stuff being manufactured, less shipping, less to lug about on the run or otherwise on the go, and less space consumed in homes. I still like to have a book to deface with my thoughts bled all over it, but I'm sure I'll come around to the idea I have to let Amazon or Barnes and Noble own the storage and format for my notes...

7/6/10 Fractals

The latest "this week on TED" alerted me to the ☼Benoit Mandelbrot talk at TED 2010. It is really charming! And that led me to ☼Ron Eglash on African fractals, and it is really interesting and especially so, when thinking about the implications of fractal strategy--I wonder if this 2007 TED talk inspired Bezos?

3/4/11: Sadly, Benoit Mandelbrot died on October 14, 2010 at the age of 85.

7/6/10 That PICTURE IT...

Ok, so the ☼video of the PICTURE IT talk is not exactly the stuff of viral excitement, but I reread the script (what I planned to say) and it makes some points I still think are worth making... and what's more, they are unique even if I do also point to the likes of Dan Roam who didn't beat me to the insights but certainly beat me to print! :-)

Speaking of beating to print, David Sibbet has a book coming out soon--yes, there are several self-published Grove books, but this one is published by Wiley, so more likely to reach more broadly and "count" among those who like the formality of a book and the vetting process that formal publication presents. Anyway, without even seeing it, I will with confidence highly recommend it!

Visual Meetings: How Graphics, Sticky Notes & Idea Mapping Can Transform Group Productivity, will be available in stores August 9th, 2010.  

7/6/10 Iterative Development

I drew on reviewers from across the spectrum of the Art of Change audience base, and each made a big difference to the content and accessibility of the Report. It really is a testament to the iterative process we all espouse, to have different people pulled in at different points along the way to provide suggestions and reflections and move the conversations the material invites forward. And though I joke about protecting my em dashes, the Cutter editors were wonderful--gracious but also careful. One area of flexibility on their part was allowing my Acknowledgments section, but I framed it up persuasively and they generously allowed that use of half a page. I feel strongly, though, about the improvement process, and when people pitch in the time to read and think creatively about how to make something better (and take the time to put their feedback carefully, so I don't crumple into a heap of slop) then credit and thanks are due to them.  

Now I do want to explain something--mostly to myself! Grady Booch pointed out that role of the architect in proactively catalyzing and "being the change, rather than just reacting to it" was implicit, not explicit (in the paper). I was frankly taken aback, because that is fundamental to our orientation (and prominent in our innovation and agile architecting paper Getting Past "But," for example). I reread the paper somewhat in disbelief--I mean, I took his feedback seriously because well, he's Grady, but I was also incredulous that he could be right because well, I'm me! And he was right! Rats! Grin. I later realized that it was in part an aberration caused by splitting the paper into the two parts--you see, Part Two: To Lead is to See, to Frame, to Draw is coming at the 'find opportunity and make it happen" catalyze change thing from a different vantage point than that covered in Getting Past "But," though it is still very much about architects enabling their organizations to be the change! And in part it was just the "what you're paying attention to shapes what you perceive and pay attention to" disorder that hurts all of us, and which is why validation/improvement cycles are so important. So I think I fixed it, and I'm very grateful to Grady and the other reviewers!

One thing I found interesting, and it validates the inclusion of a spectrum of reviewers, is that each zeroed in on quite different flaws. Wait a minute--they also all had very nice things to say. So between the good that was there to begin with, and the improvements, hopefully you'll like it! A lot! Hopefully...

I've had to read it too many times myself, and reading the final proof, I still see things I'd like to clarify or add (and on occasion take away). But I also like how it turned out. I even like the Executive Summary, even though it was murderous killing all those "thought children" to get it from 16,857 words to 1,100! I just hope you like the Report! Well, actually, truth be told, I hope you love it. Smile.

I told the kids "1 down, 2 to go" and Sara said "so you'll never be a normal mom again." Two? No, I'm not planning to split Part II into two parts! Grin. 

And because I allowed myself to get drawn into one Report that became two Reports, the VAP book is very behind schedule but I'm excited about where that is headed! I didn't tell Sara though.

7/8/10 Leaders

I read back over a post from last month... and I liked this:

Create a sense that big things are possible, starting right where you are. Because the big dings that matter are not one narcissistic trumpet call into the screaming silence of universal indifference, but rather the concert of dings that is created when many small dings add up to something big, a change that matters. 

Like... you know, any self-promotion by Steve Jobs would fall into the "who cares" category (the universe being indifferent to narcissism) if many, many people hadn't made Apple products what they are. The leader creates the concert and ensures design integrity, and is certainly key. And so are the followers. Heroes are important to our "tribal" cultures, but contrast this (Tony Fadell) with this: "October 23, 2001 Steve Jobs forever changed the course of media and entertainment distribution when he unveiled his creation, the Apple Ipod." I have no doubt that Steve Jobs played a pivotal role--including seeing the promise in Fadell's idea. I need to find 45 minutes to listen to this ♫history of the iPod   

Dana has been reading Eragon and Eldest with the kids, and he is quite impressed. I've been too busy to listen in, but Dana relays the nuggets. For example, there's political play around who will lead, and Eragon swears fealty to Nasuada and Dana observed "when a leader follows, his followers follow." This is a point we make about architects--when there are multiple strong leaders on the architecture team, they need to pick a leader to lead the leaders (Architect with a baseball bat). No-one (generally) argues against leading by example--and sometimes leaders have to set the example of following well!

Dana said something along these lines:

When the savvy leader-seeker is looking for a leader, they look for a person who has fire burning in them, because their fire will light fires in others and get things done.

I like that!

7/8/10 Visualizing: Interesting! Scary...

7/8/10 Visualizing: Interesting! Good...

7/8/10 Visualizing Trees: Interesting Example for Architects!

This is an important map (The Afghan conflict: A map of possible scenarios) for the moment in history, but ignoring what side of the issue you land on, this is a really neat way to pull together what-if scenarios... Yes, of course we use utility trees--for example to visually pull together the (non-functional) requirements like this.

As trees (not utility) go, I like this "family tree" for Schema languages for XML.

7/9/10 Visualizing Ruth: Bother!

Cutter wanted a photo for the Report. Now, photos of me are extremely rare, because, well, that's the wrong side of a camera for me to be on (for good reason)! But if Cutter readers are going to get to see "me" then, sigh, so should mine... maybe... NOT.

7/9/10 Thing so Fragile

From time to time I've read some of Alistair Cockburn's poems and I've liked several--the Tribute to Max Golightly is inspired and moving! But tonight, tracking down something quite other (not a poem!) I stumbled on There is a thing so fragile and I love it! It is truly astonishing -- utterly lovely and meaningful. (I mean astonishing in the "fill with wonder and amazement sense.")

Ok, delight. And Cockburn's take on Kano: More features and quality.

7/10/10: I make a bold statement about Thing so fragile, and I wonder if I should explicate the poem, or my reading of it? Sometimes it is enough that another person we trust (at least enough to spend time disagreeing with them) says "utterly lovely and meaningful." So let's try that. Right now I'm quite interested in poetry that is relevant to architects, and that is one! Philippe Kruchten's The Tao of the Software Architect is another. They open so much for discussion!

7/10/10 Architecture DecisionsInclude rationale (why we did this), alternatives considered but ruled out (and why), as well as implications (what we need to put in place or do differently)

Some of my take on architecture decisions:

VAP according to Bierce, from my SATURN 2010 Tutorial

7/10/10 Innovation -- A Great Read!

And to watch:

7/10/10 VAP =d= Agile Architecting

The Visual Architecting Process (VAP) applied Agile principles to architecting before it was even known as "Agile"!" You just start learning with the cheapest design medium, and think about which challenges and uncertainties to go after early. Those that will cost a lot to change. Those that cut across the system, and have far reaching impact. Those that are make-or-break. Those that will be lived with for a long time, so we should incur the cost of "quality of life" improvement (e.g. for the development team, or for user experience) earlier rather than later. Some will be market related. Some will be technology related. And code is not the Grail, value is the Grail, so artifacts that add or shore up value (like architecture models and descriptive and prescriptive architecture documents, etc.) are peer considerations to code when it comes to weighing how to invest time/budget/attention/talent. Remember, when we think in value terms, time invested in enabling many people to be more productive  (create more value with less resources), is economically justified! Everything else applies--iteration, stakeholder participation, willingness to be wrong and renegotiate the value targeted. Etc.

7/10/10 Nice Words about VAP and Other Work

My feathers are puffed up by this compliment:

"Ruth Malan , who is co-author of one of the most brilliant methods of software architecture - the VAP...",

-- Marco Mendes, Visual Architectures blog post, July 4, 2010

So, my action item is to get the VAP/Software Architecture Action Guide book done already!! Which means I have to clear Part II of that Art of Change Cutter Report off my plate. Sorry, but as twins go, that one is kinda cute and I've grown quite attached to it. So I need to get it finished.

In the meantime, we just learn and learn, and the VAP book is shaping up to be really exciting!

Oh, right, as compliments go, this was on a Bredemeyer mailing list sign-up (so relates to the Bredemeyer Resources for Architects site) last month:

"great website with very well put together explanations, documents, etc.  nice work."  -- Stephen

In July, well, there have been even more than the usual number of mailing list signups, so that's nice. Remember, I view a mailing list sign-up as an implied compliment, because giving us contact info is a matter of trust and respect.

As for Part I of The Art of Change, I was told:

"It's an excellent Report, and quite enjoyable to read to boot."

I like that! That is exactly what I'm after--great content, enjoyable to read. Gosh, I do hope it generates enthusiasm, because I think the ideas are worth getting excited about! Fractal strategy (Jeff Bezos) and tandem architecture. IT creates the architecture of the relationship platform, so determines in key ways the architecture of the business ecosystem. Agility is reshaped over the product-market lifecycle, with primary change vectors being driven by "a creative wave of destruction" (Schumpeter) early, and diffuse ripples of change as product/application variation is driven out. I think/hope it is a major contribution to how the field sees itself, inviting conversations... If I can find some moments, I want to put the key ideas into a slideset.

7/10/10 Software Visualization and Architecture Governance

Static analysis of code against architecture rules (such as those implied by layering)

Magnus Robertsson suggests expressing the architecture rules in code, to automate enforcement of architecture rules. He lists these static analysis tools:

Slide from Magnus Robertsson's presentation -- on InfoQ

Structure 101 helps discover fat packages and classes, and tangled designs.

  • Fat -- too much responsibility, too many dependencies on it
  • Tangled design makes it hard to change the architecture, because a change ripples

Image source: Slide from Magnus Robertsson's presentation which is on InfoQ.

7/10/10 Design Rulez!

It occurred to me, seeing "Code rulez," that people who have an aesthetic sense about clothing, for example, pay a premium for design.  Right? The value isn't in just any suit, it is in the cut, the name of the designer that brings with it style, fabric choice, line, and more. So value does not simply equate to "raw running code" -- the cheap suit or the designer branded suit on the shelf are not equal in value. If all we cared about was that "it runs" ok, we would buy the "cheap suit." That is, we could by-pass explicit intentional design by talented, trusted experts at design... But we don't generally want the cheap suit! Design matters. So that the crux of the matter isn't producing a suit with just any cut, nor just cutting code. We decide what design considerations add value, and what price point we are aiming at--where the price is customer cost, yes, but also developer pain, and cost to evolve, as well customer experience factors... like safety in a car, or availability for online tax filing... [Ok, I used the example of a suit, but do you buy your jeans from Walmart? We know that more than a few people do. There is an economic bracket and use model for jeans that make jeans from Walmart makes sense. And an aesthetic bracket and use model for which it does not make sense... etc.]

Of course, Magnus is all about architecture-has-value. I appreciate the point about automating the process of finding deviance from the architecture (and we have added reference to SDM tools like Lattix into our workshops, drawing attention to this architecture governance at nightly build step in the process). And the point about acting with discipline to nip deviations in the bud before their effect compounds. But instead of saying "code rulez" I'd want to say "design rulez! Yes, design rules--it constrains (and putting as much as we can of the onus of "policing" into rules in the code, or into tools that are thrown at the code, is good). And yes, design rules--we do big things by being intentional, and explicit design with a healthy dose of design improvement/validation is intentional.

We design to achieve desired outcomes, including design integrity. Structural integrity, yes, but more--design integrity.

7/19/10: Which is not to argue for BDUF, but rather explicit, intentional design--iterative and incremental, in terms of the cheapest design medium for the design decisions that are the order of the day--in the Bucky Fuller sense of "what, at this extraordinary moment in time, should I be thinking about?" Early, I'm looking at what is make or break to get right, including what has diffuse impact, so becomes harder and harder to change the more code we have cut. But also, I want to understand the success and fail factors, what will shape the destiny of the product/market/use concept and meaning, what will shape structural integrity, what forces will impinge on this system now and as it is broadened in use/application (or scope) and scale, ... But it's not just a matter of the cheapest design medium. It is also a matter of human tendency. When we put working code in front of someone, they work at tuning that--the mindset is small delta. That's a generalization, of course, but generally once we are reacting to something concrete, the concrete thing shapes our expectation, and we tweak that. Instead of having a whole gamut of design options in front of us, we have narrowed the design space. So early on, if we really want to be creative, to explore the market and design opportunity, we need to keep people in the zone of possibility. That is a key message of Sketching User Experience--informal sketches and paper mockups convey that the concept is not a done deal; we're still working at the concept level, not at the reaction to detail level. So early, we want to play (literally, wherever possible), with concepts, with quite different sketchy designs and mockups. This helps drive our creativity and keep our circles of design influences and partners fluid and thinking dynamically about what they value. Then, as we progress through all the divergent-convergent phases on the iterative and incremental design, the scope of our attention shifts (sometimes narrowing focus, sometimes returning to broad scope to refactor given a surprise or learning) but we need to keep applying this discipline of exploring design options. And as design decisions are made, and changes to the design start to bear higher and higher cost because the design is being molded in code that many minds are wrapped around and many hands touch, we need to bring that under change control, and that is where the design rulez in tools come in very handy. That way, we spot deviations from the "rules" inherent in key architectural design decisions early, rather than once they have becomes "hard cast" in a growing web of dependencies  ... that take a lot of work and destabilize the system in unpredictable ways when we try to factor them back out.     

7/10/10 [10:35pm EST] Eh hum. What about me?

If this was planned, they weren't taking me into consideration! Hmmpf! Grin.

Saturday 10:35pm and they thought no-one would notice?

7/11/10 Kiva

Microloans that enable self-employment and upliftment of some of the world's poorest.

Competitors (direct competitors, competitors for attention, competitors for resources):

Kiva development:


7/11/10 There's Opportunity in Undelight!

Fonolo was one of Time's top 50 sites last year. What?

"Fonolo. It makes the call to that large, impersonal corporation, presses the right buttons and stays on hold for you until a human comes on the line." -- Adam Fisher, Time 50 Best Websites 2009

7/12/10 Directions for The Art of ChangeThe Art of Change

In The Art of Change (don't sigh, I'm not going to be retrospective again--more like prospective, actually), I created a model (you'll find it in table 1 when you get your hands on the paper) of the product-market lifecycle. My motivation was to create a model to use to talk about how agility is different, at different points in a large enterprise--the vectors of change are quite different when creating a concept/meaning that launches a product which creates a new market space, than the vectors of change associated with diffusion of the product concept. This includes creating product variation to more closely meet the needs of more segmented markets, improving product qualities, adapting to new uses in neighboring market segments, tuning the value stream to make it more efficient but also through deepening relationships constantly innovating on the product and the process by which it is designed, manufactured and incorporated into its various uses. Keith Frampton pointed out that the lifecycle doesn't address the "other side" of market aging/death (I forget exactly how he put it, but that is the gist of it). Of course that is a good point. There are interesting places I'd like to go with the model, as I think it serves many rich discussions. It certainly invites a much deeper discussion of agility across the lifecycle. There are implications to draw out further for product/service/solution strategy and architects, as well as for IT.

Someone kindly suggested that both The Art of Change: Fractal and Emergent Report and my SATURN tutorial ought to be turned into books. Well, that is exactly what a writer wants to hear... and whenever someone tells me what I want to hear, my internal critic shifts into high gear, telling me just that. The Art of Change: To Lead is to See, to Frame, to Draw is a cut at the same space of materials and concepts as my Art of Drawing People In tutorial. It comes at it from a different angle, using a different structural model, but it's generally the same space of experience and organizing concepts. Anyway, the encouraging suggestion was to focus on the SATURN tutorial content first. So, I guess it's good that getting that Report completed is what is up next--for my "discretionary" time slices...      

Still, The Art of Change: Fractal and Emergent Report introduces so many avenues I would love to explore and till... Likewise with the To Lead report... So, once you've read both, you can throw the weight of your encouragement behind the book you back. I wrote the Fractal and Emergent report to put our voice behind regrooving the way IT and architects are seen--helping to articulate the role of IT as a strategic (not just a cost) center of excellence that propels innovation in product and process (IT architects and implements the relationship platform and instruments processes and provides analytics to create business intelligence, which are key to finding opportunities to delight through design that fits aspiration and context, meaning and... oh bother. Please read the paper; 16,000++ words would be a lot to rewrite here)... That is an important mission, I think. But as I pursued it, I think I pulled together a practice-shaping set of constructs and models, and a book would give more scope for depth of treatment on a number of avenues that tantalize--me, at least.

Oh yeah. Books. Then people will realize that my journal is full of the most delicious pieces of wit and wisdom and they'll put quotes on signatures that say stuff like:

"From which I conclude: half don't like people to be different and the other half don't like people to change." moi, 11/15/09

Ok. Probably not.

Yes, yes, top of my list of books is the VAP Action Guide book. I need several lives: one to be a wife and mother that makes me real by being so very loved, and which gives me such delightful company in play and on the various journeys of life; one to do the work with architects that teaches, invigorates and inspires me; one to do the writing that draws me out, and along. They say that teaching teaches, and it does so marvelously because the audience is other and smart; but writing does too, because one has/wants to collaborate with thinking partners--multiple internal voices, co-authors, colleagues and peers, other authors, reviewers, and anyone who we can engage to enter the conversation and push our thinking. Oh yeah, remember this:

"As for internal voices, one of mine piped up with this: "It is very good to have more than one internal voice 'cos you can get so much more thinking done! Thank you, internal voice. I like that. Of course, this was prompted by my other principal internal voice wondering if sane people confess to having more than one internal voice." moi, 3/30/10

So much to write!

And not!

More focus on the not, I think!

* Pen to paper? Hmmm... well, I still do--for storyboarding... but that has to be an expression with a limited "shelf-life."

7/12/10 Late is Better than Dead!

Being late on a ship date may put a real ding in investor confidence--if it is big and newsworthy, like the Boeing 787.

Boeing Faces ''Pretty Tight'' 787 Delivery Schedule, By Michael Mecham, Sep 9, 2007 and More delays ahead for Boeing 787? Posted by Guy Norris at 12/4/2008. Why the delays?

" further serious slide would mark the culmination of what has been a miserable 16 months for the manufacturer, not to mention its suppliers and the 787 airline customers. It all began in September 2007 when Boeing slid first flight to November/December 2007 due to supplier hold-ups, ‘traveled work’ and software integration issues." -- More delays ahead for Boeing 787? Posted by Guy Norris at 12/4/2008

Sounds like software is getting hit by the blame bus again and that would be worth ferreting out. In the meantime, the first delay was hardware--'the need to reinforce a "side-of-body section" of the composite fuselage', 787 First Flight Delayed For Several Weeks, Jun 23, 2009

But I like this commentary:

"Boeing did the right thing. You know why?

Boeing at least with respect to the 787 is run by engineers and in their minds, the schedule NEVER dictates when a new planes flies. Airworthiness does. Two of the top three decision 787 makers are engineers with advanced degrees."  -- Boeing’s Candor on 787 Delay By John Dodge | Jun 23, 2009

I hope that all this focus on risk and safety brush-offs in industry after industry will teach us that we need to follow the architectural principles laid out the good old Constitution of the USA! Remember--separation of powers and checks and balances. Why? Because power corrupts. Madison knew that. He learned from history*. So, while we need project managers who pay attention to resources and schedule, we need architects among the critical decision makers who are charged with system integrity and empowered accordingly. Empowered to assemble the knowledge so they know the market and technical risks, and can weigh these, and empowered to weigh in on decisions that affect risk and architectural challenge.

* but ultimately succumbed to corrupting forces...

7/12/10 Software Architecture Visualization

Since you aren't following me/my software visualization list on Twitter, sigh, I'll give you a heads up anyway. Grin. I added these to the Visualization in Software page:

Please remember to let me know what tools you like to use, to help your teams get a handle on the code base, or to manage compliance with the architecture/spot deviations from it early. Etc. I and the community (at least those who value the visualization resources page or Twitter list) will thank you.

7/13/10 What's Worse Than My Journal?

I've unfollowed several people/lists that I was following just because they are so busy on Twitter. I was close to unfollowing Martin Fowler, because, frankly, I'm sorry to say... I don't really care when he's landed. But then he tweets:

"The true sign of expertise is that the more you learn, the less you feel like an expert. Or at least I hope it is."

I felt like replying to say "Oh, can I use that? That's so much better than 'the older I get, the more humble I feel...'" [Though both refer to the same thing: the gap between what I know and what I want to know only grows the more I learn.] Or... I could point him to my take on the specialist/generalist joke (which I recast in terms of technical specialists and architects)...

But I wouldn't want to draw attention to myself that way. Grin.

Anyway, I think "goodness, for such pebbles, I'll continue to scout pebble-strewn beaches." Um... That's why you're reading here right?

Like the last paragraph in the Late is Better than Dead post... isn't that in the category of the pebble that is The Scream?

7/13/10 A Leadership Moment

Dana was again telling me about Paolini's Eldest, and characterized what was happening as a "leadership moment." I'm going to have to read that chapter, so I can portray it accurately, but the part Dana told and the part I heard him read is very To Lead is to See, Frame and Draw! The leader saw that the current situation was untenable, searched for what to do, convinced himself that the really hard thing must be done, raised in himself the passion and the inspiration to play the leader--to give an impassioned speech and set the vision, be compelling and very graphic about the risks and consequences of not taking the course of action, but also being frank about the risks inherent in taking the route he laid out. He recognized that a compelling reasoned argument full of logic was not going to get the village to take the only course open to them (other than the course of inaction--which was to be doomed without doubt). Instead, he knew that he had to appeal to them at an emotional level. He rose to the challenge he set himself, and the next day was surprised to see that he was being treated differently, with the respect due a leader. By his previous actions, he showed himself credible and fit to lead, and he laid out the path to be taken. He stepped into the role, onto the plate of leadership, and others saw that by his action and his vision, he was the leader to get them where they needed to go. Interestingly, Paolini then has him look at his reflection, and see that he looked the man to lead.

Aside: The title is To Lead is to See, to Frame, to Draw because I use a fractal-inspired unfolding for the structure of the Report. But it does make for a lot of "to"s... Grin.

7/13/10 Positive Thinking -- Good for the Brain!

Look at the quote on the cover of this book: The Brain That Changes Itself. I guess I'll have to look into it!

"The discovery of neuroplasticity, that our thoughts can change the structure and function of our brains, even into old age, is the most important breakthrough in our understanding of the brain in four hundred years."

-- Norman Doidge

7/13/10 International Harp Competition

We're all taken with harp this week, for it is the USA International Harp Competition and we have leading harpists from around the world competing and it is so magnificent! It is an instrument with so many different voices, and to have such stunning talent come to us is quite marvelous! I do love Bloomington--we have an amazing music scene. It is very inspiring for an aspiring harpist like Sara to hear such talent from around the world at the very university where she is in the pre-college harp program!

7/14/10 The Education of the Architect

"2. It follows, therefore, that architects who have aimed at acquiring manual skill without scholarship have never been able to reach a position of authority to correspond to their pains, while those who relied only upon theories and scholarship were obviously hunting the shadow, not the substance. But those who have a thorough knowledge of both, like men armed at all points, have the sooner attained their object and carried authority with them.

3. In all matters, but particularly in architecture, there are these two points:—the thing signified, and that which gives it its significance. That which is signified is the subject of which we may be speaking; and that which gives significance is a demonstration on scientific principles. It appears, then, that one who professes himself an architect should be well versed in both directions. He ought, therefore, to be both naturally gifted and amenable to instruction. Neither natural ability without instruction nor instruction without natural ability can make the perfect artist. Let him be educated, skilful with the pencil, instructed in geometry, know much history, have followed the philosophers with attention, understand music, have some knowledge of medicine,[6] know the opinions of the jurists, and be acquainted with astronomy and the theory of the heavens."

-- Vitruvius, The Education of the Architect, in The Ten Books on Architecture

7/15/10 The Art of Change Free Download is Here!

Ruth Malan and Dana Bredemeyer, "The Art of Change: Fractal and Emergent," Cutter Consortium Enterprise Architecture Executive Report, Vol. 13, No. 5, 2010 http://www.cutter.com/offers/artofchange.html

Here are the papers we have written for the Cutter EA Executive Report series in the past:

  • Architecting process (innovation and agile architecting):
    Malan, Ruth, and Dana Bredemeyer. “Getting Past ‘But’: Finding Opportunity and Making It Happen.” Cutter Consortium Enterprise Architecture
    Executive Report, Vol. 11, No. 8, 2008, http://www.cutter.com/offers/findopportunity.html

  • Architect:
    Bredemeyer, Dana, and Ruth Malan. “What It Takes to Be a Great Enterprise Architect.” Cutter Consortium Enterprise Architecture
    Executive Report, Vol. 7, No. 8, 2004.  http://www.cutter.com/offers/greatarchitect.html

  • Enterprise Architecture:
    Malan, Ruth, and Dana Bredemeyer. “Enterprise Architecture as Strategic Differentiator.” Cutter Consortium Enterprise Architecture Executive Report, Vol. 8, No. 6, 2005 http://www.cutter.com/offers/strategic.html

I would classify "The Art of Change: Fractal and Emergent" under architecting process-certainly it has particular relevance to the architecting process, as well as how to set up the role, organizationally.

Yes, to download them you must either be a Cutter client or download them from the links above, which means you can download them free, save for the price of giving Cutter your contact info. But remember these are highly "pedigreed" reports, selected and edited with stringent standards of excellence. ;-)

7/15/10 Why to Believe in Others

Daniel Stroe pointed me to this clip on TED: Viktor Frankl: Why to believe in others. 1972. That was some point in American history! To put it in perspective, that was the year Steve Jobs -- and Dana Bredemeyer -- graduated from high school.

I think there is a great essay to be written about the generation coming of age in the 70's--or perhaps to be read; do point me to it if you've come across one. These were the years when students flocked to listen to an aging Buckminister Fuller hold forth... It was the age of possibility and the age of hope; an age when young people asked big questions.

Kind of like today, huh? :-)

I need to think more about Frankl's message and illustration though...

7/16/10 Apple Embarrassed by Consumer Reports...

'The reception issues prompted Consumer Reports to say it could not endorse the phone, a fact that Jobs said "embarrassed" Apple.'

-- PC Magazine, July 16, 2010

Jobs returned from his vacation in Hawaii to face the storm... So, the question I have is--did Consumer Reports test other phones in the same way they tested the iPhone 4? 

7/19/10 Framing Forces and Trends

This McKinsey article frames the importance of thinking about trends and forces that will shape the competitive landscape. Here is the framing used to launch the article on the "five crucibles of change" that will restructure the world economy:

“I never think of the future,” Albert Einstein once observed. “It comes soon enough.” Most business managers, confronted with the global forces shaping the business landscape, also assume that their ability to sculpt the future is minimal. They are right that they can do little to change a demographic trend or a widespread shift in consumer consciousness. But they can react to such forces or, even better, anticipate them to their own advantage. Above all, they ignore these forces at their peril.

Business history is littered with examples of companies that missed important trends; think digitization and the music industry. Yet this history also shines with examples of companies that spied the forces changing the global business scene and used them to protect or contribute to the bottom line.

... Today, when the biggest business challenge is responding to a world in which the frame and basis of competition are always changing, any effort to set corporate strategy must consider more than traditional performance measures, such as a company’s core capabilities and the structure of the industry in which it competes. Managers must also gain an understanding of deep external forces and the narrower trends they can unleash."

-- Global forces: An introduction, Peter Bisson, Elizabeth Stephenson, and S. Patrick Viguerie, June 2010 

I liked Gladwell's article on innovation, and the notion that key inventions are "in the air" at a point in time, about to be plucked by one or several inventors, innovators or scientists at the same time. Another way of putting this, is that forces are shaping up, histories and knowledge has aligned just so, and the "fruit" of these coming together is in reach of the creative person who is thinking about what next. You don't have to be thinking about the whole of the future! Just what's next in a slice of the future, given what we know now. Because someone else will, and they will shape the future with or without us!

7/19/10 It Would be Nice...

If you like "The Art of Change: Fractal and Emergent," please let others know how to get hold of it -- by downloading it free from: http://www.cutter.com/offers/artofchange.html. For those who'd like an overview first, here is a synopsis.

7/19/10 Re-imagine This!

I see this visualization of dependencies, and think of applying the concept to software visualization. Of course. :-)  [This is just a table, but by pulling it over on an arc, we can see the whole at once, in a limited space. The column headings are left along the top. It's a neat idea.]

Visualization is very much a matter of how much to put on one visual model, to convey with clarity and to provide a tool for analysis/thinking/communicating, rather than obfuscating.

So, what are our concerns (e.g., inter-component dependencies and coupling, responsibilities and cohesion, tracing concerns, etc.) and how do we elevate these as visual elements so we can grok what is obscured in or hard to sift out from the code?

7/19/10 Visual -- Misc

7/19/10 Innovation Misc

7/19/10 I Want One!

I was thinking that a neat design goal is that "I want one" kind of reaction!

It occurs to me that these two snippets are points on that path to "I want one" greatness:

  • "desire as driver for stories" from visual sketch notes by Eva-Lotta Lamm on Scott McCloud's talk at UX2009

  • "Moments that matter--memorable moments to punctuate experience," sketch notes by Kate Rutter Exposed Conference : Sketchnotes, Breathing life into buildings, p2

Why? Because we want products/services that enhance meaningfulness, and stories are how we make meaning--in our conception, we figure out what the object or experience of desire is, we tell stories about it, we build it.

See -- I want one!

7/20/10 Exposing the Invisible

Here's a nice analogy to push our thinking about software visualization: Nick Veasey: Exposing the Invisible. TED Talk 2009

7/20/10 MacPaint Source

This great news by way of Grady Booch's blog: MacPaint and QuickDraw source code is now available on CHM. Pascal! This is one of the reasons I think that great code is like great poetry--you have to work to understand each, because the form is sparse, but as you do, you gasp at the beauty of the encounter and the mind that made it!

There's also the oral history: Bill Atkinson and Andy Hertzfeld, MacPaint Oral History conducted by Grady Booch, 2004, Computer History Museum; transcriptsketch of design structure matrix

7/20/10 NDepend

7/20/10 Code Metrics and Architecture

details that matter7/21/10 Details That Matter

When my Do Architects Need to Code post from 2007 got blogged and tweeted in May, I was struck that that was the topic, of everything that I've written, that got so much interest! Well, of course there are strong opinions--there is nothing like getting one's "hands dirty" to know that section of the system. Still, don't we want the architect to know the system? Now, for a small system, staying intimate with the code is one thing. And its quite another to be intimate with 1 million LOC! So that's where code visualization tools like NDepend come in really handy. But static analysis only takes us so far. I mentioned Tracer back in May. Has anyone looked into it? I'd love to know what you think, and what you use to grok and see the evolution of not just the static structure of the system, but how it works.

On his email signature, Mark Lane (President of the CAEAP) has the following:  "A Enterprise Architect must not only see the forest but also know the trees." A system architect must not only see the trees, but know the mushrooms and other delicate flowers and structures. But when we get to the small details, they are thematic. By which I mean, we can't possibly pay attention to each and every detail, so we have to learn how to look, and what to care about. And the looking is important. And I cycle back to Agassiz and observation. And "the pencil is the best eye." That is such a profound lesson! A camera is pretty good, because it gets us to look differently, to see detail and lighting and structure/composition differently. And a pencil is wonderful, because to draw something, we really have to see it--in our mind's eye, if we're designing. Yet drawing it out, drawing in the details that matter given what we're going after, and leaving off others, we see more, afresh, keenly. Dana asked me to help him find a bug in a piece of code he was writing, and he'd narrowed it down to a section of code, but just couldn't see it. Well, I couldn't either. It wasn't in the code. I asked him to draw what he wanted to happen for me, and as he did, he realized an assumption he was making. He probed, and indeed it was an assumption about a boundary condition. That's why I said it wasn't in the code. We make these assumptions, and often we don't even realize we've made them--it's that blink intuition stuff that goes on preconsciously. And drawing and explaining and discussing, helps us draw these out. That's true at the system level, and it's true in the details of the code.

7/22/10 Collaboration

"inspiration a gift, returned and yet kept" -- moi, Tides That Move Me

7/23/10 Weaving Ruth

The other night I was challenged to list my "favorite 3" journal entries, and the implicit point of the challenge was if I can't recommend "favorite entries" in this journal, I can't expect it to generate buzz, and perhaps I should rethink the style and content. It is kind to be concerned, and I much appreciate that.

My first reaction was that that isn't the point. I try to look past defensive first reactions... Still, I have raked over this value/form and format turf (too often) already, and have (tentatively) concluded that I shouldn't discount the value this journal has to me, being part idea-sandbox and part travel-log of my exploration through the territories central to and neighboring on all that is significant to being a great architect. And beyond that, it is more as a flow rather than as isolated entry that I expect there is value... As for word-of-mouth, isn't it possible to say "if you want to explore in the neglected areas of our field--the areas neglected that is, by the mainstream of our experience as a developer and up-and-coming architect--then this is one fine scout to check in on from time to time"? Or something like that.

Possible, but not likely. If I was asked, instead, to pick 3 representative entries, these might feature among them:veil of words

Delight and curiosity. Humor and humanity. Courage and advocacy.

Courage and advocacy. Well, I confess, not so much courage--I keep this a quiet backwaters place. There's the veil of words. And there's the metaphoric photos of entryways and flowers, and pictures of children. The "Q<= writes here" voodoo warnings that hopefully keep those with no sympatico with my style and predilections from stopping off here. Oh, right, and poetry. Gosh, no poetry (references, but no quotes) yet this month. I'll have to fix that! How about this:


may came home with a smooth round stone
as small as a world and as large as alone.

-- ee cummings, maggie and molly and millie and may

You can listen to it here: Eric Whitacre's composition and here: Natalie Merchant's. Comparative listening. We learn so much through alternatives, don't we? And yet in the rush to code, the forward rush of "sprints," we invest so little in developing or finding them. The architect has to say "fast here, and not so fast here."  Sometimes the best way to move forward is to move laterally first, and sometimes we have to backtrack. So, we try to do as much scouting as we can as cheaply as we can.  [It is silly/naive, don't you think, to foist all this onto the process, not the experience and good judgment of architects?]

What we see depends not only on what we look at, but where we look from, and I look from a different place than you. Not everyone values that. But I do. I learn so much from the "otherness" of others. Similarities and points of contact that validate what I do and think, but differences that enhance and stimulate new syntheses and eurekas. I came across the term "brain crush" the other day (specifically, “Adaptive Path has a brain crush on Dave Gray') and I like that! Hmm, let's see, at the moment I have a brain crush on Tim Brown (I'm reading Change by Design), I've long had a brain crush on the likes of David Sibbet and Eb Rechtin and the lineage of many of my thought children trace to the recognized fathers of the fields I work in. But when it comes to thought children, I'm afraid I'm quite promiscuous. I ruthlessly (or ruthfully) pursue Brian Zimmer because to me he is the engineer's engineer, the architect's architect and the (geek-) artist's artist--the combination of which makes him one of my architect heroes. I have many, but I can't point to most of them because they are hidden behind NDAs and have no public persona. People impact us, in big ways and subtle ways.

Eric Whitacre's personal story of the impact of his teacher on his life is deeply touching:

"I often think how lucky I was to have stumbled blindly to the place where David was teaching, and in retrospect I am struck speechless at the thought that our paths might not have crossed. Were it not for Maestro David Weiller I would have had a drastically different life, and it is to him, with infinite love and overwhelming gratitude, that I have dedicated these works."Qualities kiviat: factors in scope decisions because there's only so much rope...

-- Eric Whitacre

Daniel mentioned the story of Athena and Arachne in the context of kiviat/spider diagrams (and my sketch of archman making tradeoffs among qualities with "only so much rope"--that last is a reference to Dan Pritchett), but the story has particular relevance to giving credit**. The myth of Athena and Arachne, the web and weaving, reminded me of this post, and weaving a magic carpet of the dreams of the team. And giving credit. How I do cycle! But it is something we perennially have to deal with as architects! One way to lead, is to give direction and shape to, provide context for, the creativity of the team, so that being so empowered, they make something great but they do so as if without strong reigns to give direction, no forcefully wielded baton, no high command. That is the way of the Tao as reflected by Kruchten. We can't do that and overtly, persistently, "mark the territory," in dominance hierarchy, credit-claiming terms. The polar alternative is to take the credit and the flack, the way Steve Jobs ostensibly does. That is more the leader as mythical god:

"Recently it came to me the figure of Alexander the Great. His ding is enormous and his figure served an example for generations since. His empire was ephemeral, still it brought tremendous prosperity through opening new markets and facilitating exchanges (including Afganistan which had an Hellenistic culture surviving a long time after Alexander). A leader that was perceived as god, a common practice in Rome and a way that an empire - a human construction - is held together. Once such beliefs evaporate, such constructions will decay, like the corpse after soul's departure. Such beliefs are given by the many and maintained by the leaders through qualities, PR and propaganda / branding. Today we do not perceive anymore leaders as gods, still there is enormous reverence or hate toward them."

-- Daniel Stroe, personal email, July 15, 2010

Alternative leadership styles. Or something in between. I love the recognition in that "the way a human construction is held together." Software is a collective workproduct--the system and the team that creates it are human constructions. What holds the team together, directs it, gives it meaning, is what gives the system coherence and integrity. What is that? A shared conception, a shared dream.

And so we weave, and the lineage of what we weave traces back to tellable and untellable sources, and where we can tell the source we should!**  Returning to Whitacre. There is an important lesson and striking humility and frankness in Eric Whitacre's account of his composition for Three Songs of Faith and in particular I thank you God for most this amazing day. It isn't a story of attribution, but it is a story of the fallibility of intellectual pride, and these things are related.

Dana just got back from teaching our EA workshop in Chicago. His flight up was delayed. His luggage only arrived at 3pm during the first day of the workshop. So the first day he taught in shorts and a Hawaiian shirt. He went with a beard, but shaved it off on the 3rd day. People in the class asked if this was something he usually does. No, actually--he doesn't usually start teaching in shorts sporting a "been hiking/camping" beard, then start to dress more business-appropriate, then shave, etc. But Dana can pull it off. He barely turned the projector on--couldn't the first day because the cables were in the checked luggage that United so kindly delivered about 18 hours after his 30 minute flight from Indianapolis had landed... When I began my SATURN tutorial, I used the opening lines from The Emperor's Club--"the end depends upon the beginning."  I'd used those opening lines once before. Both times the technology barfed. Somehow, things go wrong, and if we stay resourceful, the end depends in surprising ways on the beginning. The common saying is "if life gives you lemons, make lemonade," but it strikes me that life tossed lemons at Dana, and he juggled them. (Dana is multi-talented--he can juggle, ride a unicycle, play the guitar and sing, has taught kayaking in the San Francisco Bay, writes more code than words, talks about Rumi as comfortably as algorithm design, etc.) Ok, so the end depends on the beginning, and it helps, at the outset, when there are high (but appropriate) expectations. In this case, the architects had either read our Cutter papers and cruised our website or they work with peer architects and managers who unequivocally say that our workshops have been the most transformative class of their career. Imagine a class that is transformative! There are lots of software/tech classes that teach. A workshop that you recommend to others because it transformed and enabled you, is something well beyond that. So, you see, I am very proud of our Dana! And there is something important, in that story, about credit or attribution. Not only is it rewarding for us to hear that our work was transformative (if we didn't get to hear that, our work would have little objective, external validation of its significance), but it was important to the experience of new generations of architects encountering our work. The attitude we start out with, affects our openness to experience and learning--of drawing forth from within, and changing mental maps--adding to, shifting, refocusing, transforming.

And so these things cycle. I am open to learning, I engage with experience and thought and the thinkers who think them, I take in what you offer me. Weaving. And unlike Arachne, I do try to give credit to my teachers, but there are so many, and the excitement of making the new weaving sometimes carries me, and I'm careless. Dana foremost fills me with ideas, some his directly, and many that trace their lineage to something he shared. Of everyone I e-converse with, Daniel is the most wonderful scout, for he is incredibly generous in sharing his quests and they range where I wouldn't otherwise think to go! Others are too. But, well, that's what it's all about--collaborating dynamically and asynchronously so we enable more and more in the world. Creating awareness: we've gotten this planet into such deep trouble! Creating ability: complexity and the need to collaborate to handle more and more sophistication in the intellectual products--designs--we create. We can navigate our way through the so-quickly massing piles and piles of facts, or we can collaborate in the navigating and the meaning-making, to enable great, wonderful accomplishments that ever push what mankind can do, and hopefully, by developing a real sense of community and shared destiny on this troubled "spaceship earth"  (a Bucky Fuller term), we can turn the trajectory around and head for better! Pebble from Lasqueti island (summer 2009): The earth's pain, in a pebble

Cycling again:

may came home with a smooth round stone
as small as a world and as large as alone.

for whatever we lose (like a you or a me)
it’s always ourselves we find in the sea

-- ee cummings, maggie and molly and millie and may

This interview with Natalie Merchant gives an interesting perspective. This too. The back-story is so interesting! And it's sad that we don't think to keep better account of the back-story to systems and their architecture. But this journal is where I trace my back-story. A trace of my journey as I romp and roam within others' thoughts and constructions, and my own. Daniel, referring to Samuel Pepys' diaries, asked why I journal. I replied "I write to engage." To engage myself, and others--the rare others who care to be so engaged, that is. To engage with the great dragons and demons and sprites and angels of ideas. Daniel replied: 'I like your "write to engage," is this ludic openess? Or socratic shepherding?' Well, both, of course, and more, my dear man.  But I do so like how you put it!

The backstory. Dana told me the story of the HP 250, and a wonderful book the team had made that documented it. I wish we still had it!

So, head crush. Is that a very Q<= way to put the admiration we feel for someone who's thinking, exploring, creating we admire? Well, just to be clear, I have more than a head crush on Dana Bredemeyer--I have a serious heart crush too. :-)        

** I try to do that.  If ever you feel I've slipped up, do please tell me! Or if I should reference something, but have neglected to/just not seen that opportunity, tell me! It is not just my role but my deep orientation, so just assume it was an unintended oversight.

7/23/10 Upcoming Workshops

Dana Bredemeyer will be teaching two open enrollment Software Architecture Workshops in Europe (both classes will be in English):

Yes, we'll hold an open enrollment workshop in the US in late October. And yes, I'll likely teach that. Well, at least that excites me!! :-)

7/24/10 I Want One! NOW!!

Oh wow! Have you seen Note Taker on the iPad? Way to go Dan Briklen! :-)

I see that Ivan Sutherland's SketchPad PhD dissertation has been republished. Bear in mind that was completed almost 50 years ago.

Ok, now model recognition if you please.

7/25/10 Coupling and Cohesion, Modularity and More

the classics!


coupling and cohesion

wikipedia entries:

coupling and cohesion metrics

strategies and patterns to achieve loose coupling

(loose) coupling -- other kinds of systems

  • Herbert Simon, Sciences of the Artificial

  • Karl Weick, "Educational organizations as loosely coupled systems", Administrative Science Quarterly, 21 (1976), 1-9 (part).

  • "The Management of Organizational Change among Loosely Coupled Elements" (1982) by Karl Weick reprinted in his book Making Sense of the Organization (2001)

  • James Douglas Orton and Karl E. Weick, Loosely Coupled Systems: A Reconceptualization, Academy of Management Review 15 (2)

related concepts/practices/concerns


responsibility driven designThinking through "how this will work" helps find responsibilities which will be factored onto architectural elements (component specs)

  • Wirfs-Brock and Brian Wilkerson, CRC paper, OOPSLA 1989

  • Ward Cunningham and Kent Beck, CRC paper, OOPSLA 1989

  • "Object-oriented design: a responsibility-driven approach" by Rebecca Wirfs Brock and B. Wilkerson, Conference proceedings on Object-oriented programming systems, languages and applications, 1989.

  • Object Design: Roles, Responsibilities, and Collaborations By Rebecca Wirfs-Brock, Alan McKean, Nov 8, 2002

  • articles and presentation files you can download at http://www.wirfs-brock.com/Resources.html

  • Rebecca Wirfs Brock and Alan McKean, ObjectDesign: Roles, Responsibilities and Collaborations.

  • Kent Beck, Ward Cunningham, A Laboratory For Teaching Object-Oriented Thinking

  • applicable sections of Michael Feather's Working with Legacy Code

modularity in software

modularity in product architecture



code smells


  • Refactoring: Improving the Design of Existing Code By Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts, 1999
  • refactoring, c2 wiki
  • refactoring, Martin Fowler's bliki
  • Refactoring Part 1: A general introduction to refactoring. Eberhard Wolff interviewing Martin Lippert

factoring/refactoring in the large
[perhaps we should say functionality preserving, rather than behavior preserving... e.g., we're good if the refactoring allows us to scale up to the next plateau, but not if it breaks a use case/user story... or if we refactor to improve fault tolerance... etc. Alternately put, we can still do the "what" and we should have improved the "how well."]

dependency injection/inversion of control

contacts and protocol design

interfaces and roles

information hiding and encapsulation

open/closed principle

case studies and examples

technical debt

tools -- static analysis (most focus on modularity, coupling, granularity, etc. issues and have implications for making technical debt visible)

tools - performance analysis (useful in making aspects of technical debt visible, like code coverage)

In the work we do with architects, I have assumed the foundation is there, but I wanted to have some level-setting background material for those who need it. 

7/25/10 Design Thinking

Kent Beck's Responsive Design Lessons So Far (listed as "The Tour") is awesome! And guess what--one of the lessons is "play with pictures"! With pictures! It's not only this Q<= who talks in terms of pictures! Oh, right, I do so because I want to include group graphics, rich pictures, ad hoc diagrams, and models--UML models, SysML models, analytical models, etc. Yes, the good stuff of Visual Architecting.

There is a "palette" of diagram types in this post. It's a nice idea, and links to my BI pyramid model (that leverages/refers to David Sibbet's knowledge model).

I mentioned I'm reading Change By Design--it's been on my reading stack for months, but I was too busy writing about design thinking to read Tim's book!!! Oh well, I'm reading it now. I love the story he starts with. I noticed right off (I scan the pictures first, what can I say) that he has a diagram that is our "circle of innovation" model, just labeled "desirability," "feasibility," and "viability" with arrows instead of circles. Kent Beck uses a three legged stool instead. We have a client who has done the same (used the stool image, that is). Well, of course Tim Brown has a section on visual thinking. I like this point: "drawing forces decisions." And a section of getting our hands dirty, namely prototyping--building to think. You might remember that I've pointed to Tim Brown's talk on TED on creativity and play. The really neat thing about Tim's book is that it is full of stories.

7/25/10 Visioning

Kent Beck's Write your own fan letter rivals Amazon's "write your press release before you start," and Jim Highsmith's Design on a Box (I've called it a "cereal box vision" after Luke Hohman's game in his Innovation Games book). If you've followed along (e.g., attended a workshop, read Getting Past "But", looked at our VAP posters, looked at our Action Guides, read this journal, or my blog, etc. Grin), you'll know that we like to use a derivative of The Grove's Cover Story Vision graphical facilitation chart and format. It combines the good stuff of group graphical facilitation, and there are the dimensions of the "voice of the customer" (what great things users, buyers, folk in the value stream are saying) and the "voice of the business" that are important to capture, to make the vision compelling and vivid to various stakeholders and also to establish the charter for important things that need to be done in the system and its architecture. (It is hard to get to the big value delta in architecture/design unless we are clear that there are goals that we will make haphazard progress toward by trial and error and without explicit reflection and intentional design.)

Still, the fan letter is minimalist and agile, and a good way to get the first level of buy-in to your idea, so you can get the broader input you need to create the level of vision that will inspire and align a multi-functional team-of teams--in Getting Past "But" style.

7/27/10 Remembering

July is a month for celebrating and remembering several people who touched me deeply.

In memory of Randy Pausch. His influence and insight still touches me.

7/28/10 Some Interesting Numbers!

"Legacy code amount

  •  In 1990 there were an estimated 120 billion lines of source code being maintained (Ulrich, 1990).

  • In 2000 there are already about 250 billion lines of source code being maintained, and that number is increasing (Sommerville, 2000).

  • An average Fortune 100 company maintains 35 million lines of code (Müller et al., 1994).

  • These companies add in average 10% each year only in enhancements (Müller et al., 1994).

  • As a result, the amount of code maintained doubles in size every 7 years (Müller et al., 1994).

  • Older languages are not dead. E.g. 70% or more of the still active business applications are written in COBOL (Giga Information Group).

  • There are at least 200 billion lines of COBOL-code still existing in mainframe computers alone (Gartner Group)."

-- Jussi Koskinen, Software Maintenance Costs, 2003

Anyone seen an update on numbers like this?

For example, this is a pretty old number (from the start of my career -- that's an old number!):

"Studies of software maintainers have shown that approximately 50% of their time is spent in the process of understanding the code that they are to maintain (Fjeldstad & Hamlen, 1983; Standish, 1984)."

-- Jussi Koskinen, Software Maintenance Costs, 2003

I need to scout for more up-to-date numbers -- if you of know of any, please let me know!

7/28/10 Hard to Catch

Heron on Lake Monroe

It is better to watch herons from the kayaks than to photograph them, since it is hard (for me anyway) to hold the camera steady enough (on somewhat choppy water) for the amount you have to zoom in on these rather timid birds. But, of course, that hasn't stopped me from trying. :-)  (And no, I haven't braved taking my SLR out on the kayak, though I'm getting there.)

The water was high for a while in the early summer.standing to look at the fish

Hobie mirage drive kayaks are not graceful and elegant like a (traditional) sea kayak, but they do make for a great workout and like minivans, they are kind of the family compromise transport. They are very stable (and being leg powered, use the strongest muscle groups), and even when Sara was 2 or 3 years younger (so 7 or 8 years old) I wasn't worried about her being alone on her Sport (that she inherited from Ryan when he moved to the more graceful Revolution). We can cover pretty good distances, though last time we were out with the kids, I spent a good bit of the return trip holding Sara alongside and pulling her along--but such are the options on these very stable kayaks.  Anyway, with it being too hot and humid to run, we're taking advantage of Lake Monroe being just 10 minutes from home to put-in, and within minutes from there getting out into the wilderness where heron are abundant and the bald eagles are so exciting and magnificent to watch.


During yesterday's few mile lap on the lake, my camera fogged over and quit (it's very humid), so I gave up on trying to find a way to capture the scene (the forested hills alongside the lake diminish in the context of the expanse of the lake and the sky, and it is hard to find a composition that does the loveliness justice). The moment I stopped focusing on composition, the world became noisy with cicadas! It was like they'd kept quiet all the time I was looking at the scenery and the herons with a frame finding view--but of course, it was just my attention that made it seem that way. In Eldest, Eragon is under training in the skills of a Rider, and he immerses himself in the perspective of an ant colony and discovers many tiny details about their life and society, but his mentor is disappointed, because he could say nothing about what else was happening in the forest while he so focused on the ants. Eragon is a dragon rider, and he has the advantage of being more than human. But we, we have this characteristic that what we are paying attention to, shapes what we perceive and pay attention to. So, we have to learn to shift our attention from the detail to the system, to become aware of the context, and the interactions, the trace between goal, strategy, tactic and outcome and the tradeoffs and balancing that has to be done. And focus on the detail, where that is architecturally significant. The key though, is that this is part of the critical "thinking like an architect" that we have to develop--paying attention to the system, and system outcomes like system integrity and value from synergy (or collaborations among the parts, and between the system and other systems and entities in its context). It is also why the architect role should not be seen and staffed as a "parachute in/get yanked out after architectural design" kind of thing. Software systems evolve, and this evolution can be entirely emergent from happenstance, or guided and reflected on and intentionally shaped. For this last to happen, there needs to be a role--and a person (or team, in very large projects) in that role--that is responsible for the architecture. If the architecture is "everyone's responsibility" then that focus on the the next code drop, the next build, the next mod to get the current user story working, will dominate attention--and architecture will subside into inattention. Architecture requires tradeoffs, tough choices that have to be thought through and advocated. Attention that has to be wrestled away from the detail, and paid to the system, to systemic forces, to cross-cutting concerns, to the wash of entropy, to the pull of vested interests that constantly work their agenda.

And you thought that for once, just for once, I wasn't going to write about architecting! Ha!  

So, how did those Hobie kayaks fit in? Well, compromise and tradeoffs come to mind. Gosh, family life is very much about compromise and tradeoffs, isn't it? But I also learn so much I wouldn't otherwise. Like, I'd never have imagined I could power two kayaks (an extra ~150 pounds, given the weight of the kayak and child) for an hour... I mean -- little me! And that becoming-real-through-being-loved thing, that's cool too!

It is funny how things come together. I referenced Ivan Sutherland's classic "Technology and Courage" essay on my "Weaving Ruth" post, and it occurred to me while kayaking with just my thoughts for company, that Courage is a wonderful treatise on risk. Which brings me back to the topic I started the month with (finding stories for the "inspire" part of our "inspire and enable' teaching style for a segment of an evaluation/improvement/validation customer intervention/workshop, if you must know). I like it when cycles complete so neatly! [A lot of the essay focuses on academic research, but much applies with little effort in translation to system development.]

7/28/10 Adding "With" to the 6 Interrogatives  

I stumbled on Alex Matthews blog (he has a description with some pointers to tree/heat maps). Well, of course you know we use the 6 interrogatives for organizing access to various content areas on the Bredemeyer Resources for Architects site (have done since its inception in '98, though I'm looking at a site redesign... as soon as I get the book done. Right!) Anyway, Alex adds "With" to the interrogatives. Nice idea! Of course, "with" should point to our "Fractal and Emergent" strategy and tandem architecture paper, should it not? Grin.

Ah, so many opportunities to refer to it. But only one opportunity to be the first to do so! (Here's an overview, if you want to provide a "teaser" along with the link to the download.)

7/28/10 Interesting Window on History  

7/29/10 Innovation and Creativity

These by way of Anne Merkelson of The Grove (on LinkedIn):

I want to highlight these points from "The Creativity Crisis" article:

'A recent IBM poll of 1,500 CEOs identified creativity as the No. 1 “leadership competency” of the future.'

"To be creative requires divergent thinking (generating many unique ideas) and then convergent thinking (combining those ideas into the best result)."

"When you try to solve a problem, you begin by concentrating on obvious facts and familiar solutions, to see if the answer lies there. This is a mostly left-brain stage of attack. If the answer doesn’t come, the right and left hemispheres of the brain activate together. Neural networks on the right side scan remote memories that could be vaguely relevant. A wide range of distant information that is normally tuned out becomes available to the left hemisphere, which searches for unseen patterns, alternative meanings, and high-level abstractions.

Having glimpsed such a connection, the left brain must quickly lock in on it before it escapes. The attention system must radically reverse gears, going from defocused attention to extremely focused attention. In a flash, the brain pulls together these disparate shreds of thought and binds them into a new single idea that enters consciousness. This is the “aha!” moment of insight, often followed by a spark of pleasure as the brain recognizes the novelty of what it’s come up with.

Now the brain must evaluate the idea it just generated. Is it worth pursuing? Creativity requires constant shifting, blender pulses of both divergent thinking and convergent thinking, to combine new information with old and forgotten ideas. Highly creative people are very good at marshaling their brains into bilateral mode, and the more creative they are, the more they dual-activate."

This, from the same article, is interesting:

'In middle childhood, kids sometimes create paracosms—fantasies of entire alternative worlds. Kids revisit their paracosms repeatedly, sometimes for months, and even create languages spoken there. This type of play peaks at age 9 or 10, and it’s a very strong sign of future creativity. A Michigan State University study of MacArthur “genius award” winners found a remarkably high rate of paracosm creation in their childhoods.'

in the light of this: breaking confining conception. (Implying nothing about my kids, but only pointing out how much leveling our society masses against creative and unusual play.)

7/29/10 For Kindred Seekers

Reading that post (breaking confining conception), I find I like it--it might percolate up as one of my favorite 3, or at least one that is representative. There is so much in that post that is enormously important to creativity and architecting and my role in this field, and it is full of eureka-level convergent insight, playfully written. And, yes, the number of people that will grok it is certainly limited both by its references (like, who has seen The Rockae?) and by its style. So? I expect only extraordinary people to read here--extraordinary, kindred bliss-following, awe-struck seekers (an adaption of Grady Booch's "awe-struck seeking" and "follow my bliss" which itself borrows from Joseph Campbell's 'follow your bliss").    

"Yet it is important to note that following one's bliss, as Campbell saw it, isn't merely a matter of doing whatever you like, and certainly not doing simply as you are told. It is a matter of identifying that pursuit which you are truly passionate about and attempting to give yourself absolutely to it. In so doing, you will find your fullest potential and serve your community to the greatest possible extent."

-- Follow Your Bliss, Joseph Campbell foundation

'Now, I came to this idea of bliss because in Sanskrit, which is the great spiritual language of the world, there are three terms that represent the brink, the jumping-off place to the ocean of transcendence: sat-chit-ananda. The word "Sat" means being. "Chit" means consciousness. "Ananda" means bliss or rapture. I thought, "I don't know whether my consciousness is proper consciousness or not; I don't know whether what I know of my being is my proper being or not; but I do know where my rapture is. So let me hang on to rapture, and that will bring me both my consciousness and my being." I think it worked.'

-- Joseph Campbell, The Power of Myth, 1988, (First Anchor Books ed. 1991, p149) 

7/29/10 Luminaries

I stumbled on Scott "Doc" Andersen's blog the other night, and this post is heart-warming: What or Who is a Visionary.

I will have to write a post on the luminaries that light my sky--which is, of course, an extension of the "Weaving Ruth" post, but also with a finer focus. Grady Booch certainly features prominently among those that light my thinking. Martin Fowler too--more, the more "human" he allows his projection to become. ;-) But there are luminaries, and there are influences, and my influences are so vast and diverse (like Keith Moore, Joe Sventek, Rob Seliger, Dean Thompson, ...)! And there are people who changed the trajectory of my life, and to whom I am most grateful (like Martin Griss, Derek Coleman, and Todd Cotton). Well, lots to think about there! Another time!

7/30/10 Architecture Principles

An Architecture Principle is a normative statement that orients (or steers) and aligns decisions and actions so as to achieve strategic outcomes. That is, Architecture Principles focus and guide decisions, shaping direction to address factors critical to achieving strategic intent (or strategic/architecturally significant system outcomes). Well-stated principles cleave the decision space between decisions in line with the principle and decisions that run counter to the principle.*

Rob Seliger introduced us to architecture principles in the early days (i.e., in the mid '90's) of working on what would become the Visual Architecting Process. We, like Rob, used the guidelines described in Paradigm Shift as a starting point, and to avoid "motherhood and apple pie" principles, we added counterarguments to the template. There are those, like Mark Schultz, who argue that architecture principles "are statements of preferred direction or practice. They reflect a level of consensus among the various organizations within an enterprise." We notice that they are statements of direction or practice that we need to develop consensus and action around, to create focus and align decisions to achieve strategic intent. For example, we might need to change the status quo to implement a shift in strategic direction, or to do something consistently that we have only being doing in isolated instances because it involves hard choices and tradeoffs. If we are going to take a minimalist approach to architecture, then we look to the minimum we need to do to ensure that the right things happen to achieve the strategic outcomes our business seeks. So we don't want to state general good principles which are good practice but not something we should extend and encumber the architecture decision set with (everything we add to the architecture consumes attention of those who create and maintain it, those who need to understand and act in accordance with it, and those who govern it).

Which begs the question--how long-lived are architecture principles? As business strategy and architecture drivers change, we want to revisit the set of principles, looking to cull principles that no longer apply, adding principles that reflect the new direction. Once a principle is enculturated within the organization, we may continue to keep it in the architecture decision set if it is a point of uniqueness to our organization and we find that as we onboard new developers and architects (new hires or through acquisitions), the principle is important to helping bring them into our organization's (technical) culture (for technical principles) with its norms and principles guiding decisions and practice. 

So here's the template we advocate:

  • principle name: catchy!
  • principle statement: clear statement that will guide decisions addressed by the principle to be in accord with and achieve strategic intent/architecturally significant system outcomes
  • rationale: what benefits we get from following the principle (motivating why we have to change what we do); provides traceability to strategy or system/architecture objective the principle will help us meet
  • counter forces (aka counterarguments or alternatives considered): provides a place to say we recognize what factors weigh against the principle and what other approaches we might take (that other people in our environment would argue for) and why we shouldn't do that. One way to think about the counterargument/counter force, is that it illuminates implications/things that need to be done to ensure the principle is followed/viable in the social/business/technical context. It provides a place to say "in the face of dilemmas and tradeoffs and pressures we tend to do this, and this is how it hurts us" and "we could alternatively take this other approach, and this is how that would hurt us."
  • implications: what we have to do to as a result of and to facilitate following the principle
  • scope (optional, as relevant): the intended scope of impact of the principle (explicitly denoting decision scopes to which the principle does not apply, so that these don't have to go through the exception request process, assuming the principle is tended under the governance process).

I broadened counterarguments to counter forces to explicitly direct attention at any forces (including counterarguments or alternatives that others may try to use to displace the principle) that may impede our ability to follow the principle. These will give rise to implications, or things we need to do to ensure that the principle is technically viable and organizationally feasible. Other kinds of implications are the downstream consequences of the principle, issues we will have to take care of, etc.

3/8/11: Responding to a tweeted question about guiding principles for EA, I mentioned the Architecture Principles page (where examples of principles and other references are collected) on the Bredemeyer site, as well as our Principles for Architects page (you know, describing the Minimalist, With Teeth and Connect-the-Dots principles).  Of course, guiding principles for enterprise architects are more like the second, and less like the first. The minimalist principle drives our approach to principles that will be formally collected under the rubric of the enterprise architecture. What we call these things and how we treat them, is going to have something to do with whether they are going to be part of our architecture (formally), and hence under governance. In other words, do teams have to motivate (and even formally request an exception) their decisions when they run counter to the principle, or is it something they can treat as simply a guideline? If the latter, perhaps we'll just call it that -- a guideline.

That said, architecture principles are a mechanism to express values in terms of behavioral/decision guidance, and are an important way to shape culture. They are part of the "left hand" work of shaping and guiding culture so that the architect can use a lighter touch approach (see, for example, p16 of The Art of Change: Fractal and Emergent or here or here). I suppose there are a few guiding principles for architects contained in that right hand left hand image, but minimalist says go with the lightest touch approach that will create the strategic outcome. ;-)  

Principles are normative – they express how things should or ought to be, how to value them, which things are good or bad, which decisions or actions are right or wrong. It might be tempting to overdo our prescriptions here. Every principle we add to the architecture, consumes cycles -- creating and evolving the principle statement, understanding and following the principle, and governing the principle (otherwise they'll be ignored) all costs attention (see discussion/motivation in Principles for Architects). In other words, we can view Architecture Principles as a lever to help set and maintain direction/course, so long as we don’t get overzealous and wash out their impact by having so many we overload the attention space and cause them to be ignored.

If, by "architecture principles," we meant fundamental laws ("facts of nature underlying the working") of software or enterprise systems, the discussion and guidance would be a lot different!

A guiding principle is a rule of behavior that leads to good things; in architecture, we mean a specific approach that leads to good designs. For example, this statement contains a guiding principle: "Conceptual integrity can be achieved by uniform application of a limited number of design forms." p. 31 Bernard Witt, Terry Baker and Everett Merritt. Software Architecture and Design: Principles, Models and Methods. p. 9. Van Nostrand Reinhold, 1994

Clearly we are not saying that architects shouldn't collect, organize, disseminate and teach guiding principles/approaches that leads to good designs. The point is only to separate general education of the development teams from principles that are formally used to shape the direction and decision space.

I'd love to hear how you think about principles and where you agree or disagree with what I have proposed as the template and guidelines for its use.

* 1/14/12: I've moved two sentences from within the discussion (where they were quite buried), and added a third, to the beginning to provide orientation and placed them in italics. You will notice that this reframing draws on the discussion of 1/14/12 between Kris Meukens and Ernest Buise on Twitter. (Two statements were already there, with a word change here or there to sync up with the third sentence.) Anyway, if I improved on what I had done it is thanks to Kris and Ernest, and I think (hope!) placing an orienting statement at the beginning of the Principles post makes is more helpful!

Note: Strategy is fractal, so we mean strategy at the level of scope we're working at -- business strategy for enterprise architecture, product or service strategy for the related system architecture.

7/31/10 Software Visualization

The software visualization community seems to have focused on one meaning of visualization -- forming images of the design implicit in the code, etc. That is, there is a focus on the existing system, and making aspects/characteristics/dimensions of the system visible. So, for example, the structure of the system is rendered; a picture is formed. I think, however, that both the following meanings are useful: forming images of system as intended (imagined, designed) and forming images of the system as it is. Then we have visualization applied to design intent ("smoke") and design reflection ("mirrors"). The focus on the (static) code visualization problem, liberated the conception of software visualization from our standard for visual design expression (the UML and sysML). This has meant that there has been creative exploration of forms and metaphors useful for visualizing existing systems. The apparent desire to distinguish and demark the field of software visualization, with its side-effect of highlighting weaknesses in design expression/visualization, has this plus side, but we need to be alert to where one informs and is informed by the other, because ultimately we would like the evolution of the design expressed in code and actualized in the system to inform and be informed by the evolution of design intent. The software evolution we want, is that which is driven because our intentions evolve, rather than devolution that comes because we have less and less design traction and start to make more and more ad hoc changes to the code (to try to keep pace with evolving intent or goals/objectives/needs). If there is a divergence between the way we express design intent, and the forms and formats for expression/reflection of the design (structures, mechanisms and processes) inherent in the code and dynamic system behavior, then we have to create mechanisms to translate between the two. That's ok too, if we can tool the translation process, but it is more transparent, there is less to learn, etc., if the same expressions serve both the design thinking/improving and the exploration of the design of extant code and running software.

Visualization: What?

visualize [www.websters.com]

–verb (used without object)

1. to recall or form mental images or pictures.

–verb (used with object)

2. to make visual or visible.

3. to form a mental image of.

4. to make perceptible to the mind or imagination.


visualization or visualisation [www.websters.com]

— n

1. the act or an instance of visualizing

2. a technique involving focusing on positive mental images in order to achieve a particular goal

Visualization: Why?

  • answer a question

  • make decisions
    - support analysis and reasoning

  • to explore and discover, encourage creativity
    - to look at things in a new way

  • communicate information to others
    - make a point
    - tell a story

  • inspire
    - part of our cultural heritage

  • amplifies cognition/perception [Card, Schneiderman, MacKinlay, Readings in Information Visualization]

-- Source: Pat Hanrahan, Stanford CS448B: Visualization

Stanford CS448B Readings list

How visual models help:

  • Increase understanding of complex systems

  • Explore and compare design alternatives at a low cost

  • Form a foundation for implementation (code generation, reverse engineering and round-trip engineering)

  • Capture requirements precisely

  • Communicate decisions unambiguously (using UML or sysML)

-- Source: Eclipse Concept: Visual Modeling


Stanford Info Vis Resources

Other Resources

7/31/10 Good Design and Code Value

Culturally (meaning in our techno-geek culture, not national/geo-centric cultures), we place emphasis and value on code. So much so, that we tend to endanger explicit, intentional, documented design. In the heat of the moment, turning out code rather than explicit design artifacts wins--and we keep turning up the heat!  Even in a "lean" kanban orientation that includes a requirements/business analysis stage, we have pressure to go from requirements to code. The kanban process in lean software development might be called cascades, though this wouldn't be "sexy" in view of the antipathy we've developed around waterfalls--instead of big drops, these are broken into many small drops that are repeated as the system is built out in small increments, so there is more communication between the specialty disciplines of the work stages as work "flows" between them. These mini-stages and the WIP pull orientation keep the heat turned up. (Others things too, but the effect of the heat is what I'm highlighting here.)

Now, I drew on the designer clothing analogy* earlier because it occurred to me that we need ways to express the value that is in good to great design (where the measure is in business terms, but including a valuation of structural integrity). Yes, the design is realized in code, and often the only design thinking that is happening in a transferable way (taking it outside the head of the thinker), is happening in the medium of code. Then the question is, are better designs created simply in the medium of code, or in other media and mediums (including code, but potentially in targeted prototypes)? And can we afford to invest in better designs -- indeed, can we afford not to? All the arguments that are massed along the lines of "we don't know enough" and "we don't know what we don't know" and so forth, argue for more exploration and experimentation--so long as much of it can be done more cheaply!

So, yeah, sure it becomes a management issue--do we resource experimentation or do we just resource (fund and staff) building code? After all, until we have running code the "goodness" of the design is a moot point, and increments of working code are the best vehicles for testing customer acceptance and adjusting based on that ultimate of tests, application in the real world. Right? Well, no. "Best" is context sensitive. If there is high uncertainty about the value model and/or the design, we can explore options and alternatives quickly and cheaply using paper mockups (including sketches and models), role play, performing thought experiments and making reasoned arguments, etc. Given the uncertainties, risks and challenges we face, design is about getting options on the table (divergent gathering of alternatives) and combining elements and ideas to form a convergent approach that will best achieve our desired outcomes (acknowledging the balance between where we seek to delight and where we will satisfice--recognizing that this too is a design space that we iterate on). So there is also a leadership issue, and a question of what we choose to advocate, and enculture. Yes, yes, I know all about pushing rocks uphill. And cutting code to do ad hoc in-situ design is a "letting rocks follow gravity" kind of approach.

If we want to get out from under the rule of the Kludge, to avoid the "big ball of mud" as dominant design, and create more modular, more evolvable, persistently mutable systems, we need to design for that--and keep designing for that!. If we want to create hub architectures that become the platform for flexible, evolving relationships, we need to design for that. Etc. We design to achieve desired outcomes, to direct our intellectual and team/community effort at making the system more the way we want it to be. Which means also deciding what that is, which is itself a design activity!

Now architecture is about the design of the whole, of the system--the design of the parts, yes, but so as to achieve the design goals, outcomes, objectives of the whole; to achieve fit of the system to its context and intended purpose; and hey, to dynamically, collaboratively find out what that intended purpose is, even! Architecture is about design across boundaries. The boundaries or joints within the system. Yes. But also across the boundaries of the system. And design across the contexts of use. And design to accommodate axes of change we have high confidence will factor as we evolve the system.

If you are discounting this post as ho hum Ruth at it again, you do us both a disservice. There are important additions to the common way that architecture is talked/written about in the above paragraphs--along with the same old drum beat. New nuances throw light not just on how we articulate and "sell" architecture, but also have implications for roles and responsibilities. For example, we see that in a fractal approach to system-of-systems design, there are overlapping roles/responsibilities at boundaries within the system and across systems, and the system architect collaborates with, but follows/is led by, the system-of-systems architect. And so on up and down the scopes of systems.

And we are saying that design has its own payoff in value that is greater for explicitly, intentionally scouting out value and challenge, articulating strategies for  addressing those, then creating concert among minds to figure out how to build something better than a purely add and adjust, reactive kind of approach would produce. The concert among minds part is why we need to document our designs, and evolve them (intentionally evolve the designs, but also reflect design decisions made in the code back into the design artifacts). To ensure design intent, including structural integrity (within the design envelope we negotiate with those investing in the system), we need to design and develop a shared conception of the system design--its goals, strategies, organizing structures and mechanisms.

So, yes, complex systems are that--complex--and complexity tends to be correlated with big, meaning a lot to grok. This means that visualizations of the system structure are important, and ways to navigate--to selectively reveal more detail--are important. That is where much of the work in code visualization has focused. But we also need to gain intellectual traction so that we can effectively engage more minds in creating a great system. And we need to have better ways to figure out where to focus these great minds and the work they collectively produce---ways to find the value model that will create differentiating business advantage for our organization.

All of this speaks to the need to design, and to leverage visual design at that. UML, yes! But informal sketches like Rich Pictures are an important design tool. We also like The Grove graphic facilitation templates and our derivatives and spin-offs (like Stakeholder Profiles). And where we are using the UML, at points we work very sketchily--specifically when we're simply exploring and probing, covering a lot of lateral ground as we discipline ourselves to think divergently and get options on the table. But as we converge on a chosen approach, we use selected UML models along with text to specify key decisions. In short: 

Good design enhances the value of the code. 

Now. And into the future.

And good design protects the value in the code.

Now. And into the future.

Because, YAGNI advocates notwithstanding, today's future slips so quickly into the past, and we have to be careful what we declare we won't need! It is a judgment call, not an absolute.  

And good design generally takes considered, collaborative work to produce. Considered--intentional, explicit, imaginative explorations, reasoning, testing, probing, trying, advocating and countering, ... Collaborative--drawing on and drawing in diverse other people with ideas, expertise, perspectives, ...

* I've seen the gap between revenue and assets and market cap used as an objective valuation of branding, and branding is increasingly related to design, rather than (only) advertizing spend. Well, I didn't think that is an adequate picture, but it gives another way of articulating the recognition that design has value.            

[Aside:  YAGNI arose as a discipline correction (correcting, for example, our technologist tendency to gold-plate); but overcorrecting is also detrimental.]

Ok, Daniel, do you want to ask me again why I journal? By unraveling that thought I got to Good design enhances the value of the code. And good design protects the value in the code. If you configure and reconfigure words, eventually some combinations fall out that you like! Call it epiphany. Eureka. Insight. Vanity. Whatever. :-)  I'm teasing myself. But framing is important, and while Dana Bredemeyer and Grady Booch seem to have an incredible knack for catchy turns of phrase that orient and inspire action, I have to work at finding them. Dana? Well, how about "good, right and successful" and "goodwill is the silver bullet"?

I know, what I landed on sounds an awful lot like "right product, built right" (which is so commonly used that I have no idea who to ascribe it to). Yet, to get the design of the product and the design of its guts more right, we have to do more design--where design is the practice of making things more the way we want them to be (Herbert Simon). That isn't the same as advocating BDUF, but rather agile architecting that precedes and accompanies agile development--informing and being informed by iterative and incremental development. So we embrace a combination of explicit, intentional design, and implicit, emergent design (in the medium of code) that we reflect on and may decide to refactor or evolve the design documents to reflect.


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: July 1, 2010
Last Modified: July 30, 2010