A Trace in the Sand
Online Architecture Journal
by Ruth Malan

I also write at:

- Resources for Architects

- Architecture Action Guide

- Trace In the Sand Blog
 

HelpMatch:

- HelpMatch Wiki

- HelpMatch Google Group

 

- Other Interests

 

Trace in the Sand
Architecture Journal

- Journal Map

2011

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- Current

2010

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December

2009

- January

- February
- March

- April

- May

- June

- July

- August

- September

- October

- November
- December

2008
- January
- February
- March
- April

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

2007
-
January

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

- September
- October
- November

- December

2006
-
February
- March

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

- October
- November
- December

Topics

- Innovation by Amateurs

- Power of Community

- Collecting Jokes

- HP's Hurd

- Roadmaps, Projections and Scenarios

- Principal Principles

- Steve Vinoski on REST

- Want vs. Needs

- My Genie

- Cost of Quality

- Organic Architecture

- Dalgarno Links

- Bernard Merckle

- Analogies

- Complexity

- Epiphany

- Architecture Experiments

- The Art of Possibility

- IT as Strategic Enabler

- Business Intelligence

- Gears

- Distinguishing Values

- Power of Stories

- Serendipity Revisited

- Giants Who Reinvent Themselves

- Visualization

- Construction Techniques

- Collaborative Teaming

 

 

 

Blogroll

Chief Architects

- Charlie Alfred

- Rob Daigneau

- Don Ferguson

- Thomas Lee

- Brad Meyer

Chief Scientists

- Grady Booch

- Martin Fowler

Enterprise Architects

- Todd Biske

- Adrian Campbell

- Leo de Sousa

- Paul Homan

- James Hooper

- Nick Malik

- Jim Parnitzke

- Serge Thorn

- Tim Westbrock

Architect Professional Organizations

- CAEAP

- IASA

Architects and Architecture

- Simon Brown

- Louis Dietvorst

- Kevin Francis

- Sam Gentile

- Adrian Grigoriu

- Simon Guest

- Todd Hoff

- Alan Inglis

- Steve Jones

- Dave Linthicum

- Anna Liu

- Ruth Malan

- Chirag Mehta

- Gabriel Morgan

- Robert Morschel

- Dan Pritchett

- Chris Potts

- Arnon Rotem-Gal-Oz

- Shaji Sethu

- Leo Shuster

- Collin Smith

- Brian Sondergaard

- Michael Stahl

- Daniel Stroe

- Jack van Hoof

- Steve Vinoski

- Mike Walker

- Rodney Willis

Agile and Lean

- Scott Ambler

- Elizabeth Keogh

Software Reuse

- Vijay Narayanan

Other Software Thought Leaders

- Jeff Atwood

- Scott Berkun

- Alistair Cockburn

- CapGeminini's CTOblog

- Joel Spolosky

CTOs and CIOs

- Rebecca Parsons

- Werner Vogels (Amazon)

CEOs (Tech)

- Jonathan Schwartz (Sun)

CEOs (Web 2.0)

- Don MacAskill (SmugMug)

Innovate/Tech Watch

- Barry Briggs

- BoingBoing

- Gizmodo

- Dion Hinchcliffe

- Oren Hurvitz

- Diego Rodriguez
- smoothspan

- The Tech Chronicles

- Wired's monkey_bites

 

Social Networking/Web 2.0+ Watch

- bokardo.com

 

Leadership Skills

- Presentation Zen

 

Strategy and Competitive Intelligence

- Freakonomics blog

- Tom Hawes

 

Um... and these
- Nick Carr

- Tom Peters

 

Green Thinking

- Sylvia Earle, TED

- CNN Money Business of Green videos

- Matter Network








 

 

 

April 2009

4/1/09 April Fool's Day

A day just for fools—like me! I succumbed to my own need and opened the lid on this journal just a crack—enough to let Google in.  You see, with 3 years of documenting my exploration and thinking about what it takes to be a great architect in this journal, a Google search on my domain is more effective than my memory at locating links and points again.

Photo right: Peach (peace) Blossom, 4/1/09

4/1/09 Reinventing the Auto—Overthrowing the Dominant Design

"Since we can't predict the future, we're focused on creating it."

"I sleep like a baby: I wake up crying every two hours." 

— Larry Burns, Reinventing the Car, TED Talk

4/1/09 Invention by Amateurs

Given that Innovation is Waning, US Leaders Worry, should we be concerned? In The Rise of the Amateur Professional talk on TED, Charles Leadbeater makes the following case (paraphrased from Leadbeater's talk):

Who invented the mountain bike? The invention didn't come from a bike company. It came from a group of young bikers in California, who mixed-and-matched parts from various bikes. It was ten to fifteen years before the big companies saw the market and started manufacturing mountain bikes.

When the internet combines with passionate users, you get an explosion of collaboration, because it provides a mechanism to organize without formal/traditional (closed) organizations. The result is that these open groups can achieve even large and complex tasks without formal organizations.

Most creativity is cumulative and collaborative. Users are the source of big, disruptive innovations. It is hard to find disruptive innovations in large organizations. Why? Do you go to the board with an embryonic idea for a new market, which is high risk? No, you go to the board with incremental, safe ideas. They have an in-built tendency to reinforce past success, because they have so much sunk in it. Take for example, the music industry and rap music.

Which venture capitalist will put up money to create a competitor to Outlook? That is why the only competition will come from alternate (open) organizations.  

Intelligent closed organizations will move in the open direction, and will mix open and closed in interesting ways. More companies will be based on communities—providing the community with a platform and tools.

"One reason open organizations are successful is that they multiply our productive resources because they change users into producers."

[4/21/09] See also "The next step in open innovation," by Jacques Bughin, Michael Chui, and Brad Johnson, The McKinsey Quarterly, June 2008 (you can register as a visitor to read a subset of articles, including this one).

4/2/09 97 Things

The 97 Things an Architect Should Know book is in bookstores. 

4/2/09 Qualities Links

Integration Patterns

Scalability

Scalability isn't just an infrastructure issue, and design for scalability has implications for software architects:

"Why is scalability so hard? Because scalability cannot be an after-thought. It requires applications and platforms to be designed with scaling in mind, such that adding resources actually results in improving the performance or that if redundancy is introduced the system performance is not adversely affected. Many algorithms that perform reasonably well under low load and small datasets can explode in cost if either requests rates increase, the dataset grows or the number of nodes in the distributed system increases.

A second problem area is that growing a system through scale-out generally results in a system that has to come to terms with heterogeneity. Resources in the system increase in diversity as next generations of hardware come on line, as bigger or more powerful resources become more cost-effective or when some resources are placed further apart. Heterogeneity means that some nodes will be able to process faster or store more data than other nodes in a system and algorithms that rely on uniformity either break down under these conditions or underutilize the newer resources.

Is achieving good scalability possible? Absolutely, but only if we architect and engineer our systems to take scalability into account. For the systems we build we must carefully inspect along which axis we expect the system to grow, where redundancy is required, and how one should handle heterogeneity in this system..."

A Word on Scalability, All Things Distributed blog, Werner Vogels, 3/30/2006

Speaking of algorithms...

4/3/09 Leveraging the Power of Community

The Open Cloud Manifesto is a great example of leveraging community action to create change and momentum. By creating community advocacy for an open cloud, any vendor working to define their approach to, and tools for, the cloud in a closed manner is crossing lines drawn by the community. It is pre-emptive community action to try to avert monopolistic practices from shaping the cloud. 

4/3/09 Collecting Jokes

Well, I've been gathering up some jokes/odd bits of humor:

Do you know what the difference is between a technical specialist and an architect?”

“A technical specialist spends their entire life learning more and more about less and less, until eventually they know everything about nothing.”

“While an architect spends their entire life learning less and less about more and more, until eventually they know nothing about everything.” 

adapted from Charlie Alfred's blog post

On being promoted to one's level of incompetence (about HP's CEO, Mark Hurd):

"Our theory on people was that you give them responsibility," says Gilbert Williamson, a CEO of NCR during Hurd's rise. "To my knowledge, every time we threw Mark out the window he landed on his feet. So we moved him up a floor..."

Mark Hurd's Moment, CNN 2/27/09 (and Fortune magazine, 2/2009)

The differences between the genders leave a lot to laugh about

"Thought for the Day: Married men should forget their mistakes. There is no need for two people to remember the same thing."

This one is good for talking about the importance of visualizing/drawing:

Sir Ken Robinson's "drawring" joke is great too, and it works for architecture—you know, when you're sketching your architecture live, you can tell the joke and follow it up with "but no-one knows what the system will look like" and "they will in a minute." And then you can talk about the setting in which the joke is told—the setting being a child's willingness to take a shot, to be wrong, and set your audience up to give you input because you have shown boldness in taking a shot, but also humility and a willingness to be wrong.

On visualization and perspective:

where the course gets tougher

Quotes about humor and leadership:

“Imagination was given to man to compensate him for what he is not; a sense of humor to console him for what he is”

-Francis Bacon, Sr. (English Lawyer and Philosopher. 1561-1626)

“Keep your sense of humor. As General Joe Stillwell said, “The higher a monkey climbs, the more you see of his behind.””

-Donald Rumsfeld (American Secretary of Defense)

Liven up a meeting with funny signs:

Allen Klein, an award-winning professional speaker and author of The Healing Power of Humor. His favorite funny sign: "Never wrestle with a pig. You both get dirty, and the pig likes it."

19 Ways to Enhance Your Sense of Humor, Reader's Digest, 12/1/08

I read through several jokes on the Reader's Digest joke site, and this one tickled me:

It is so rare to be offered a meal on airlines these days that I was surprised to hear the flight attendant ask the man sitting in front of me,

"Would you like dinner?"

"What are my choices?" he responded.

"Yes or no," she said.

You want a tech joke—try this one. And funny stuff on this site—including engineer jokes like this one:

"Normal people ... believe that if it ain't broke, don't fix it.
Engineers believe that if it ain't broke, it doesn't have enough features yet."

And all because "we're going to be dead for an awfully long time!"—we might as well have some fun while we're still here. Actually, I'm hearing from various sources (Don Norman, Tim Brown of IDEO, etc.) that play, fun, humor is important to creativity. And creativity is important to innovation--in the large, and in the small.

4/3/09 HP's Hurd

On time management and doing what's important:

'As it turns out, Hurd can tell you exactly how much time he spends with employees, customers, shareholders, and so on, thanks to that spreadsheet he keeps to manage his time. In fact, he can break the "customer" category down by segment and by what portion of the "total available market" he personally has approached. The point, he says, is to be mindful of his scarcest resource. "I only have a certain amount of time to spend," he says. He doesn't read books, has played golf only three or four times in his life, and devotes the rest of his leisure to playing tennis, watching sports or movies, and hanging out at home. His customers in Phoenix were dejected that he wasn't joining them for the All-Star Game. Said Hurd: "I've got a family."

Customers still feel loved, though. "He is personally self-effacing, modest, unassuming, and, I dare say, shy," says Jeffrey Katzenberg, CEO of DreamWorks Animation, which runs its digital studio on HP gear. "But you get him talking about his business, and he explodes." Hurd also is attentive. Christian Anschuetz, chief information officer for Underwriters Laboratories, says Hurd was quick to send a congratulatory note when Anschuetz took a new job. "There are people below him that are far less responsive than he is," says Anschuetz, adding, "I have two large outsourcing contracts I'm planning to put out for bid. You'd better believe I'll make sure HP gets on the list."'

Mark Hurd's Moment, CNN 2/27/09 (and Fortune magazine)

If you get push-back on spending time at (potential and angry) customer sites, just point to Hurd. If he can make time to pay personal attention to (selected) customers, so can architects—and so should architects. Hurd needs this access to customers so he can have good intuitions about priorities. Intuition—or the subconscious working of the mind—is absolutely vital when it comes to tradeoffs. Yes, you have to have good intuition about the technical ramifications of your decisions! And good intuition about the ramifications for customer value, for creating engagement and delight. 

Roadmaps, projections and scenarios4/3/09 Roadmaps, Projections and Scenarios

Often when people talk about roadmaps they're talking about product/portfolio roadmaps, which are used to track and manage feature releases and make visible, and so better manage, internal and external project dependencies. Architects use and contribute to these roadmaps, tracking technology/infrastructure dependencies and planning for capability development.

But technology roadmaps can be used as a strategic tool, not just a project planning and management tool. Indeed, this is a great time to demonstrate the value of using technology roadmaps to explore opportunities and threats. Dana Bredemeyer likes to call roadmaps used for this purpose "projections." Of course, the companion tool is "scenarios" a la Art of the Long View — you could call these "what if" scenarios.

Stephen's list of questions (on the Bredemeyer Software Architecture Workshop Alumni LinkedIn group) has primed us for a great set of "what if" exercises. Yeah, it takes time and who has any with shrinking headcounts, but let's put aside the panicky reactions we've been seeing all over the place, and focus on looking forward. It is energizing to be thinking "It's Spring!" (at least in the Northern Hemisphere) and "What are our paths to renewal and growth?". The purpose of these "projections" is to think about what changes should feed back into the product/portfolio roadmap (at least in the form of contingency plan footnotes).

What are the big trends that are going to overshadow all else over the next 2, 5, 10 and 20 years, and how do we position for those? (Is 20 years too far out? Hint: "engineers tend to over-estimate what they can do in one year, and under-estimate what they can do in ten" — I believe it was Bill Gates who famously said that, though he was prefaced.)

  • Where does climate change go and what does it mean for various industries? Insurance? Energy? Military? Transportation? Agriculture? How does all that spill over into implications for your industry?
  • Where does the "Necessary Revolution" (Senge et al) in cradle-to-cradle production, use, and recycling take us? Are we running out of critical minerals, depleting the oceans, drawing down forests and canopy, putting mercury into our water supplies...? How does all that spill over into implications for your industry?
  • How does social networking change the way business is done, and what organizations look like? how products are invented? built? marketed? supported? We see the precursors to a lot of change, and we need to think about how these forces are likely to impact our industry...
  • How does the cloud reshape the landscape? Software productivity trends? (So significant threats in a variety of industries can come from under-25s with little to no funding! More and more, the only barrier to entry is not being tech-savvy, and having too much to lose...)
  • How does globalization—and deglobalization—change things?
  • What are the other big landscape reshapers we should have on the radar?
  • And that is just talking about the "big stuff" that is obvious to me. With each trend, we can ask what does this mean for our business? What specific opportunities and what threats do we see emerging?
  • How do we get consumers and corporations to take their foot off the spending brake with opportunities so compelling they just have to get excited?

I've been thinking we need to get corporate leaders to talk about their economic stimulus plans... to do that, they need IDEAS—indeed, a projection/roadmap. Yes, yours! (Rah rah! etc.)

And this is not just the bailiwick of chief architects like Stephen, Allister and Charlie. In times like these, we can't afford not to own the success of our companies! (Again, rah rah! etc.)

So, I guess you'll be busy this weekend. :-) But remember, the best projection flavored roadmaps are created in a diverse team. (If you're having a hard time finding girls to play too, I just happen to know one.) And you might want to experiment with de Bono's six hats.

Or, you could just take the porcupine approach.

"Everyone's hurting, but especially companies clinging to old business models."

— Jim Zemlin, interviewed on LinuxDevices.com

4/4/09 Principal Principles

Jeff Wallk suggested the following general themes for EA principles:

  • Agility: ensures we can respond quickly to changes in business needs
  • Efficiency: ensures we can deploy technology with a low consumptions of resources — human and otherwise
  • Adaptability: ensures the technology can embrace change — timely, easily, and where possible w/o human intervention
  • Extendibility: ensures the technology can scale (vertically to meet growth volume of data & users, and laterally to meet growth in complexity of functionality)
  • Innovation: ensures we can bring new value to the business by identifying new technologies, leveraging existing technologies in creative new ways and pioneering technology where possible through collaboration and by encouraging ideation

I really like that!

4/9/09 Steve Vinoski on REST

I watched Steve's QCon talk on REST on InfoQ last night. Now, Steve is the ultimate in self-effacing, and while the fact that I've long admired him may not impress you, his record should stand for itself. And when he has swung about face on RPC-styled architectures and is pitching REST that means something! Steve (like Charlie Alfred) is championing Roy Fielding's dissertation as a landscape reshaping moment in software architectural history. I strongly recommend Steve's talk, and Roy Fielding's thesis. So, who is designing REST-styled architectures?Happy Easter Blossoms on IU campus, April 2009 I'd love to hear how you are thinking about that and see what you are doing.

4/12/09 Happy Easter/Passover/Chocolate Day/Just-Another-Day Day

4/13/09 Wants versus Needs

This cartoon from the New Yorker caught my attention.

While taking a walk on the funny side, this Dilbert is Hagy-good!

4/13/09 You're My Genius!

One evening last week, I unwound watching TED videos on creativity-related topics. Elizabeth Gilbert talked about where creativity, or inspiration, comes from, and relayed the ancient Greek and Roman thinking on creativity:

"But, ancient Greece and ancient Rome — people did not happen to believe that creativity came from human beings back then, OK? People believed that creativity was this divine attendant spirit that came to human beings from some distant and unknowable source, for distant and unknowable reasons. The Greeks famously called these divine attendant spirits of creativity "daemons." Socrates, famously, believed that he had a daemon who spoke wisdom to him from afar.

The Romans had the same idea, but they called that sort of disembodied creative spirit a genius. Which is great, because the Romans did not actually think that a genius was a particularly clever individual. They believed that a genius was this, sort of magical divine entity, who was believed to literally live in the walls of an artist's studio, kind of like Dobby the house elf, and who would come out and sort of invisibly assist the artist with their work and would shape the outcome of that work.

So — brilliant — there it is, right there that distance that I'm talking about — that psychological construct to protect you from the results of your work. And everyone knew that this is how it functioned, right? So the ancient artist was protected from certain things, like, for example, too much narcissism, right? If your work was brilliant you couldn't take all the credit for it, everybody knew that you had this disembodied genius who had helped you. If your work bombed, not entirely your fault, you know? Everyone knew your genius was kind of lame. And this is how people thought about creativity in the West for a really long time."

transcription of Elizabeth Gilbert's TED talk 

So, it occurred to me—you are my genius! Anything good I write is entirely up to you! I'm pretty good at configuring words, and you're the genius on the front lines of learning about architecture. It is all so much clearer to me now, thanks to Elizabeth Gilbert! Of course, if my work bombs, I won't say my genius was lame! Still, you know and I know it's all up to you. 

4/14/09 Technical Debt and the Cost of Quality

Martin Fowler has a nice post on technical debt. It might be worth pointing out that while some people manage their finances carefully without even giving it a lot of thought, others get themselves into crippling debt and leave the rest of society to pay the price of their indiscretions.

Bad code becomes a broader societal problem and we need to start to take our systemic impacts into account! This isn't just true for embedded systems code, though I want to be sure that my steering and brakes are going to work all the time, under any conditions that might be thrown at them. It is also true, though perhaps not life-threatening, for web applications. Perhaps. If I had a short fuse and was prone to hypertension and suffered from high cholesterol, some of my experiences with time wastage and lost data might have put my life in jeopardy... Nonetheless, some of these experiences have cost the vendor in question business, and others have tarnished their image (which may cost future business). That's what bleeds out in terms of direct impact to the customer of unintended (so hard to "test out") consequences of technical debt.

It can help to visualize the technical debt, using tools like Sotoarc, Lattix or NDepend. And it helps to be self-disciplined, not incurring wanton debt for the sake of short-term gratification and unscrupulous excess.

So much for the debt analogy. It is useful, but perhaps it puts the attention in the wrong place—we start to wonder how much debt we can live with.

Because there's debt, and then there's risk, and the lessons from the quality movement apply here. First, the "cost of quality" refers not just to the cost of finding quality issues (reviews and testing) but also the cost of un-quality--the cost of defects or quality issues including those that impact product/system, and ultimately brand, integrity.

The quality movement recognized that the cost of finding and fixing defects together with the cost of defects that leak through all the test barriers and reach the market can be so high as to warrant process improvements to reduce the number of quality issues created in the first place. Well, that's in manufacturing. In development, we also need to do what is reasonable to avoid creating defects. But some of our quality issues relate to uncertainty and the concomitant chance that we make choices that turn out to be ill-advised, so we seek to discover quality issues as early as possible, to remove them before their effects multiply. But we recognize that this must be an ongoing process, as we learn and resolve some of the uncertainty. 

Quality issues that are architectural, typically carry the highest cost of change because they have systemic impact—if they are not discovered early. Architectural issues that creep up on the system, like increasing coupling and dependencies, increased duplication of code, etc., bear costs in terms of increasing the likelihood of defects and erosion of the user experience and business value. The defects may be harder to detect and isolate for the very reason that they were introduced--the impact of changes is hard to isolate. If detected late, the cost of refactoring-in-the-large, redesigning a core mechanism, etc., may be high enough that the program management decide not to take the schedule hit and ship anyway—increasing the cost of quality, but pushing out the point at which the price is paid.   

Quality issues that reach the customer have all kinds of costs that run the gamut from safety or hassle factor/productivity hits to lost business and damage to reputation/branding. The cost to Microsoft of Vista crashes is un-estimable, and the cost to users? I can't even imagine! Vista is an easy target, and I have a love-hate relationship with it—mainly, there's a lot to love, which is part of the problem. It is easy to take pot shots but one has to remember that Microsoft faces a unique problem which is rooted in its success—the user base is incomparably huge and so varied, and then there's all the backward compatibility demands, and on and on. Twitter too ran into the price of success—how much did Twitter lose when it could not scale/saw service outages? Perhaps it was just some temporary egg of their face, but perhaps it also pushed untold numbers of users Jaiku's way. At the very least, it caused the question "Who is Twitter's competition, anyway?" to be raised.

We need to broaden our quality frame from bugs that cause partial or outright system failure and specifically include design flaws and missed market targets ("requirements" or functional design flaws) into our quality considerations. Yes, these costs are hard to measure (shading into opportunity cost, which can only be estimated). But so is the cost of system failures in the hands of users. Design flaws run a spectrum from design issues that cause inconvenience, frustration or productivity loss (slow startup times come to mind) to designs that simply don't deliver the value the user seeks (the IRS modernization case study teaches by counter-example).

When design and implementation are conflated, some things become easier, and some harder. With agile, "the customer" gets a feature/story/piece of the working system to respond to, and then more, etc. Where this all fits in the systemic picture of structural integrity and system fit to context and to purpose, however, is harder to assess if no-one—not "the customer" nor the development team—holds that "big picture." Then it is up to evolution to manage the random walk that tunes out and tunes up until a dominant design emerges from all the experiments. The question then is—can this evolution be speeded up? If so, it must be speeded up in terms of finding the high payoff market target and the architecture that is a good match (fit to context and to purpose) for that conjoint value set.

Quick-and-dirty experiments (using thought experiments with hand-drawn sketches, for example) that illuminate architectural flaws early are invaluable, because the same flaws may not be found during early tests as these tend to be local (component, service and feature-centric), not systemic. 

VAP applies agile principles to architecting, to concurrently explore the value profile of stakeholders and the architecture that fits that value set. The key ideas of experiment and adaptation are driven earlier, to increase the rate of learning about the fit of the value set and design to the market and the organization sponsoring the development as well as the development teams. This learning, assuming a process that keeps the people involved flexible and open to changing the design (both in terms of the value propositions and function, and in terms of structure and system behavior), is central to adapting, and we have built mechanisms into VAP to foster learning and flexibility (countering the tendency to get one's ego locked in on an approach, and addressing the inherent filtering/bias problem).

When just enough design is done to have a good enough sense of the value propositions, system concept and architecture, the agile cycles can switch from experimenting with models and thought experiments, and proof-of-concept mockups and prototypes, to building out the system. There is still a good degree of experiment and innovative problem solving to be done, but the target (in business value and structural terms) is in the sights of the team.

Of course, once a system is fielded, the degrees of design freedom become more limited, but the market is generally better understood by that point too. 

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan

“With good program architecture debugging is a breeze, because bugs will be where they should be.” — David May

Some Twitter scaling references:

More IRS modernization references:

Collection of links and observations on software failures:

4/14/09 From Organic Architecture... to... The Grim Reaper (a.k.a. the Justice Department)

I stumbled upon and read Tom DeMarco's article "On Systems Architecture." Written in 1995, it provides a great window on history, and DeMarco's perspective on it. The "box whallah" story is a great example of an (organizational) organic architecture. Some of DeMarco's observations are grounded in his definition of architecture:

"An architecture is a framework for the disciplined introduction of change. This is also a pretty good definition of design. The difference between the two is that design, as we commonly use the word, applies to a single product, while architecture applies to a family of products."

For example, DeMarco's estimate of the cost of architecture is based on his definition—the architecture for a product family costs more than architecture for a single product.

I like this insight:

"Design is always concerned with capacity to accommodate change. This is true even of the extreme example of a system which is to be run once and then thrown away. It still makes sense to design such a system, because it still has to be able to accommodate one change, specifically the change that is the implementation process. (Here I portray implementation as a change from concept to reality.)"

In other words, design (first in models and mock-ups, then in code) helps us implement a system! This is something we've been losing track of, to some extent, in the agile movement. Models help us think! They help us deal with separate concerns separately. They help us deal with abstractions in terms of abstractions. Models are not the holy grail. Actually, nor is code! Value is the holy grail, and models (with descriptions, explanations, justifications, defenses, etc. in words—i.e., documentation) and code help us find our way to the holy grail!

[4/16/09] I watched Tim Brown (of IDEO) talk about creativity and play (video on TED). Tim makes the point that "thinking with your hands," for example by building low resolution prototypes (e.g., using masking tape and children's clay), stimulates creativity. It helps to quickly get your thinking into the real world so you can test ideas much more quickly with users. We tend to think that because code is so malleable, and because we do have very productive prototyping languages, it is the best route to these early experiments. Surely it is a good one! But therein lies the danger. We tend to overlook other "hacks"--a cereal box or storyboard, role play, pictures, brainstorm lists... Creativity needs a palette of more colors than black and white! Think "and."

4/14/09 Software Architecture and Reuse

4/14/09 Dalgarno Links

These posts by Mark Dalgarno are useful:

And this by way of Mark Dalgarno:

 

4/15/09 Architecture Analysis: Bernhard Merckle on Software Engineering Radio

Here are my notes on the interview (kudos to Bernhard and Markus Völter who interviewed him). It is not a strict transcription, and I apologize for any misrepresentation in the paraphrasing:

Architecture decay/erosion is a pervasive problem, and as the release approaches, work-arounds tend to increase. Someone (the architect, architecture team, agile team wearing architect hats) defines the architecture, but keeping it alive is not that easy. Architectural analysis tools can help ensure that the architecture of the code is the intended architecture.

Architecture analysis tools may cover:

  • consistency: check the existing architecture (the code base) against the intended architecture; you describe the architecture in a language which is tool specific, stating rules/constraints from the architecture and the tool checks these against the code. You can then do refactoring in the large. Note: tools give an awareness of problem areas, but you have to define the constraints and you have to fix the problems. You can do virtual refactoring—that is, you can simulate refactoring by moving the packages or classes in the tool to see the effect without changing the code.

  • rating: says something about internal software quality, like high coupling or bad smells. The tools generally come with predefined set of bad smells/anti-patterns; it makes you aware of the problem, and you fix it.

  • discovering your architecture: This applies, for example, when there is no good documentation. In some of the tools you get a graph layout and you can see which interfaces are not used at all, etc. Q: You want to rediscover the intent, and that is not in the code. So how good are these tools? A: They use intelligent layout and apply graph algorithms and you see essential abstractions on one diagram. They give you a good visual clue as to what is going on!

  • metrics: measure the real facts—"you can't control what can't measure." Measures include complexity, instability, and number of overridden methods. The challenge is to select the right metrics! Q: Is the value of metrics not the absolute value but rather how they evolve over time? A: The trend is also important but the absolute number is important—e.g., look at outliers.

  • monitor changes over time: coupling increasing? —find out while there is a chance to reverse the trends. Most of the tools do monitor over time so you see the trends. That way you can catch and deal with a trend before it is really burnt into the project. Outsourced projects should have trend monitoring, for better project control.

Structural analysis tools:

Closing thoughts: You have to enforce the architecture, and the tools help you do this.

Bernhard Merckle and Markus Völter (interviewer), Software Engineering Radio

4/15/09 Analogies and Metaphors

4/16/09 Taking On Too Much

The tipped donkey image used on this post is great! It reminds me of an archman picture Sara drew... must scan in... must scan in... it relates to agile development. And may do a better job than the pyramids...?

4/16/09 Complexity — Simplicity

“There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.” — C.A.R. Hoare

“You know you’ve achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away.” — Antoine de Saint-Exupery, Wind, Sand and Stars

"A child of five would understand this. Send somebody to fetch a child of five."  — Groucho Marx

"A man must be able to cut a knot, for everything cannot be untied; he must know how to disengage what is essential from the detail in which it is enwrapped, for everything cannot be equally considered; in a word, he must be able to simplify his duties, his business and his life." — Henri Frederic Amiel

"Everything should be made as simple as possible, but not simpler." — Albert Einstein

Coming into focus4/17/09 Epiphany

When I was "thinking out loud" about putting a lid on my journal, Scott's was the lone voice encouraging me to persist:

'this is an architect's dream site--the very attractive embodiment of Nolan's "soul-filled bounty of mind's expanse."'

Thanks Scott! Some people will be like "Dude, that's a stretch!" But stretch or not, it was kind and I admire that instinct and the action.

Ok, so even though Scott was too kind, his characterization is something to aspire to! Wouldn't it be something to create the dream site for architects who are awe-struck seekers? A site for kindred spirits who take delight in the creative process, gasp in awe at systems nature- and man-made, and find joy in the dance of life? Kindred spirits who get Nolan's "soul-filled bounty of mind's expanse"!

4/19/09 Architecture Experiments

Experiments are important tools in the architect's toolkit. These include experiments to find and demonstrate value, and experiments to improve the architecture, especially key mechanisms. Experiments? Yes, thought experiments, prototypes, simulations, and more. Thought experiments? Yes, Einstein championed thought experiments, though I don't know if he coined the term or just made it better known. Anyway, thought experiments and reasoned arguments supported by system behavior models and back-of-the-envelope calculations can be powerful ways to find issues with the architecture, and to think through solutions.

'Making Performance and Scalability Assumptions. "Start considering performance and scalability early, create performance models to try to predict key performance metrics and spot bottlenecks and get stuck into some practical proof-of-concept work as your design ideas are forming. This will all help to increase confidence that there aren’t any performance and scalability demons lurking in your design."'

-- Niclas Nilssen quoting Eoin Woods, Top Ten Software Architecture Mistakes, Oct 2007

4/21/09 The Art of Possibility

The Art of Possibility is a book I stumbled upon and need to get--these snippets from the overview on Amazon hooked me:

"Giving an A... speaks to their passion rather than their cynicism"

'... students in his class receive an A if they write him a postdated letter relating "the story of what will have happened to you by next May that is in line with this extraordinary grade."'

Benjamin Zander is conductor of the Boston Philharmonic, and his TED talk "Classical Music with Shining Eyes" is on my watch list.

Last night, I watched Don Norman on TED (you know, Don Norman of The Design of Everyday Things). Actually, I was half-working, half-watching--wouldn't want to not be working, now would I? I was well along when I realized I ought to pay attention more closely! So... I think Don was talking about how we are wired to function: creativity needs to happen in a relaxed, playful space; and to focus we need some source of fear, or tension--like deadlines. If this is what he said, it maps well to the divergence-convergence cycles I wrote about in the Getting Past "But" paper. Grin.

I have found myself wanting to point more people to that paper of late. One architect who is micro-managing his team through the early phases has me especially wanting to help him "see" what he is doing and how he could get very different results if he shifted from trying to provide all the answers to seeing himself as forging a crucible for team creative magic to happen. I get this feeling that he is seeing all these inch-tall people, and I look and I see giants of possibility in them. But because he has shaped up beliefs about what to expect from them, he has boxed them in to giving him what he expects.

Martin Lew said something the other week that had the ring of "hammered truth" to me--"They [management] need our help." I mentioned this to Dana, and he recounted a situation where he was working with architects who'd been asked by their management team to help explore/find business opportunities, and they were griping about it and he was just floored! This team was squandering the amazing fact that their management team recognized what technologists bring to the table!     

4/21/09 IT as Strategic Enabler

The McKinsey interview with Credit Suisse CIO, Tom Sanzone, is informative. Here's a small window (free visitor registration is required to see the full article:

"The Quarterly: So how do you think about the alignment between IT strategy and business strategy?

Tom Sanzone: Each of the three businesses has a strategy to become the premier industry player over the next three years, and we have technology initiatives that can help the business achieve those strategies.

I often use a diagram of a pyramid to illustrate our IT strategy and vision and how the technology and business strategies are totally aligned. At the top of the pyramid is Credit Suisse’s overarching vision of being the premier bank. Aligned below that is how IT supports that vision by becoming the premier IT organization in our industry and by creating competitive advantage for our clients. Our IT vision is in turn supported by three pillars: integration, improvement, and innovation—a strategy we call our three Is or I3.

First, we have an extensive strategy around integration. It’s hard, and not every organization can do it. But you can do it pretty quickly as long as you make the tough calls. The process doesn’t take that long if people are aligned to get it done. The second pillar is improvement. It’s mostly about all the initiatives that are aligned with our businesses and are meant to grow revenues. So there’s a whole portfolio of initiatives within technology to improve profitability, grow revenues, and improve processes. These projects generally take longer before they deliver competitive advantage.

The third I is innovation. And while there are certainly initiatives aimed at making incremental improvements in the bank’s business, our innovation stream is really about implementing revolutionary change in the way we run our business or in creating significant new efficiencies or revenue opportunities. Technology obviously plays a key role here, since it often acts as an enabler for new processes and services. If we can create a competitive advantage in delivering our IT products to our internal customers, we’ve done our job. It’s then up to them to go out and sell and trade and do business. That’s the partnership."

Bradford Brown and Allen L. Weinberg, "Integrating diverse IT systems: An interview with the CIO of Credit Suisse," The McKinsey Quarterly, January 2007

This McKinsey article about and Indian bank CEO who is also the CIO is very interesting (90 day projects, business owns technology, etc.).

4/21/09 Business Intelligence

Another snippet from The McKinsey Quarterly:

"Few companies have successfully capitalized on the explosion of data in recent years. Often this information, residing in separate IT systems or spread across different business units, has never been mined for insights that could add value. Small teams of business and IT staffers can find opportunities by combining a detailed understanding of business processes with straightforward analyses of consolidated data sets. When such teams use the data to compare best practices across regions or to identify under- and overserved customers, for example, they can identify hotspots of revenue leakage." 

James M. Kaplan, Roger P. Roberts, and Johnson Sikes , "Managing IT in a downturn: Beyond cost cutting ," The McKinsey Quarterly, September 2008interaction of teams of teams

4/21/09 Gears

When I drew the gears images for the Getting Past "But" executive report, I hoped people wouldn't object to the mechanistic image, though I told myself readers would understand that I, of all people, would not be thinking of people as mere cogs in a machine. So, it struck me when I saw the OpenUP image that I wasn't the only one using a gear image. I was expressing the relationship between the core team and the extended teams, and I like the OpenUP way of expressing the relationship between the timeline and the iterative team cycles, etc. There's a lot more that I like about OpenUP, too, and I recommend a perusal.

4/21/09 Distinguishing Values from Principles

Values motivate behaviors and principles guide behaviors.

Mark G. mentioned Donald Shon's Learning Principle: reflection-in-action ('thinking on our feet’).

I suggested a Fit Principle: Design systems for fit to context and to need. This came out of a discussion around architects as pragmatists, and Jeff W. pointed out (in effect) that the solution has to be pragmatic too. In Think Better (my reading companion du jour), Hurson recounts a piece of technology innovation history that motivates this aspect of the fit principle quite nicely: Astronauts found their pens wouldn't write in zero-gravity, so NASA ramped up an initiative to create a pen that would address that need. In so doing, they created a technological marvel that could write upside down and even underwater! What about the Russian cosmonauts? They used pencils! It works, and costs pennies!Woodland wildflower

[4/21/09: Sara was awarded first place among 3rd graders in our area in the Reading Rainbow "Young Writers and Illustrators" competition, so her illustrated short story goes forward to the national competition!  Pretty cool!]  

4/22/09 Earth Day

Celebrating Earth Day: let's be sure we keep those woodland wildflowers!

IN woodland wildflowers

4/24/09 Serendipity or Filter, You Choose

I mentioned divergence-convergence cycles in a post a few days ago, and now I'm reading Think Better and Tim Hurson also talks about the importance of divergence-convergence cycles. He emphasizes that it is important to clearly separate these, and it reminded me of Disney's process (separate rooms) and De Bono's hats.

4/24/09 The Power of Stories

Stories are powerful! They help us imagine and shape what we could be, and these stories help others be inspired through empathy to break inertial barriers. Here is a great example:

"In 2008 Frank returned to Tanzania with the idea of getting local children to make art that he could sell back in Canada to fund the children's school costs. Working in the Kilema area with a local guide Joseph Lyimo, Frank and Lynn Bird (a member of the Rotary group) visited 30 children whom Joseph had identified as facing financial hardships to stay in school. 9 of the children who heard about Frank's visit walked for hours to participate in a project that might help them to stay in school. With Frank's encouragement each child made a drawing of their dream for their own future. In every case the children want to finish school and engage in jobs within their community. They want to be doctors, teachers, store-owners and truck drivers. They have dreams to help others and their families. These dreams are poignantly illustrated in the children's drawings which Frank has brought back to Canada along with photographs of the children and their individual compelling stories.

Back in Canada Frank shared the children's art, photographs and stories with a friend Laurie Bowers. Together with Joseph Lyimo in Tanzania, Lynn, Laurie and Frank have founded Art Building Children's Dreams, a not-for-profit organization whose goal is to use the children's own art to raise funds that will allow them to finish school and fulfill their dreams of becoming contributors to their communities." -- Art Building Children's Dreams (ABCD)

This is a wonderful use case for HelpMatch, don't you think? If we think of HelpMatch as providing the mechanisms for people to tell their stories, and for stories to be found, that is. It is much like Kiva, but more general, in that it doesn't require a specific organization on the ground collecting stories.

Stories are a resource that so many people don't consciously recognize. They empower, they shape, they motivate.

I came across the ABCD site by way of Tim Hurson's "blogs I follow." In a blog post (from October last year), Hurson recounted how he'd set up a workshop he facilitated at a creativity "mindcamp":

"We set up the premise (that you can alter your recollection of an event by the stories you tell about it) and then let people experiment and discover for themselves."

I have come to realize that not only do the stories we tell ourselves impact our perception of the past, but of the present too. The Lacy-Zuckerberg audience reaction comes to mind as an extreme example where that goes wrong--getting multiplied by mutual reinforcement when people discover they are telling themselves similar stories to those others are telling. Sometimes I've put this in terms of how we frame something up (borrowing the terminology from the Software Initiative group I worked in during my last 2 years at HP). It is something I emphasize over and over with my kids (go ahead, feel sorry for them--imagine living with me every day!). It isn't just a cup-half-full thing. The stories we tell ourselves shape our attitudes and affect our perceptual filters, which affects our behavior. It can become a self-reinforcing cycle--increasingly positive, or increasingly negative.

For example, Lacy told a story of a previous interview with Zuckerberg, where he was sweating so much his t-shirt was soaked. Some in the audience got upset at Sarah for "using this anecdote to embarrass Mark." But the alternative interpretation is that she was telling the audience that this guy is shy--shy way beyond what we imagine from the meteoric success of this young CEO--so "go easy" and let him get over his nervousness.     

This is why I found Indra Nooyi's advice so life-changing--it gave me a way to get beyond defensive reactionary thoughts. "Always assume positive intent" says look for the positive intent that could just as well cause behavior that I'd otherwise be inclined to react negatively to (get upset, tell myself more negative stories to justify my being upset, etc.). When I look for the alternate story, I keep command of my resourcefulness and can steer the interaction in a more positive direction.

This is not "seeing the world through rose-colored lenses." It does not repaint the behavior as positive in outcome or intent, but it seeks to understand the broader orientation that motivated the behavior. Someone saying something harshly defensive is not positive and may be directly intended to hurt, but passion for the good of the project or protecting reports may be the positive intent behind the surface behavior. If you assume the person is well-intentioned from their frame of reference, you have something to work with. (I wouldn't extend this to criminal and psychotic behavior, of course.)       

Serendipity revisited

I wrote the above piece, then was tracking down some references mentioned by Hurson, and by an indirect path stumbled on Michael Michalko's blog on Amazon. I scanned around the entries partly because I was struck by his rose-colored lenses, and partly because he wrote Thinkertoys. Anyway, his Roses and Thorns post struck me. It ends:

"Think of roses and thorns. You can complain because roses have thorns, or you can rejoice because thorns have roses. You can choose to interpret experiences any way you wish. It is not the experience that determines who you are; it is your interpretation of the experience. You do not see things as they are; you see them as you are." -- Michael Michalko

Just think, all the stuff that is out there, and in a mere 15 minutes I'd stumbled on a very eloquent and compelling way to make exactly the point I'd been nudging along...

Oh right--"Books [and blogs] serve to show a man that those original thoughts of his aren't very new at all." - Abraham Lincoln

It's not a happy accident (serendipity) at all. It's serious redundancy! Ugh!

Well, some music then! It's a Cruel Crazy Beautiful World by Johnny Clegg & Savuka comes to mind. Speaking of music, the IU Ballet department's choreography workshop showcased choreography and dance by students in the program last week. What does that have to do with music? Well, the range of music used was broad--from a soulful female a cappella piece (Long Time Traveller) to Ravel's Le Tombeau de Couperin. This last was a very ambitious selection, but Ben Delony totally nailed it! It was a wonderful program--Bloomington is a great town, from that point of view. You can see and hear extraordinary talent, often free. And it's not just IU's top-ranking college music and ballet program, and all the artists that visit because this is a college town. The opportunities for children are greater because it is an art-centered town. Next week, children from IU's precollege music program will play the music for the precollege ballet program. The integration of the arts has an expansive effect, giving succor to the spirit and helping to keep us from becoming cemented by routine.

4/28/09: Daniel Stroe pointed to this Epictetus aphorism:

"We are disturbed not by events, but by the views which we take of them."

So, Michalko was prefaced by Epictetus. But then, Epictetus was prefaced by Aristotle:

"First say to yourself what you would be; and then do what you have to do." Epictetus (AD 55 -  c.135) and

"If you wish to be a writer, write." Epictetus (AD 55 -  c.135)

“Men acquire a particular quality by constantly acting a particular way... you become just by performing just actions, temperate by performing temperate actions, brave by performing brave actions.” Aristotle (384 BC - 322 BC).

Ok, to make matters worse, I scrolled over the photo in my page footer from last month, and found that I'd prefaced myself! ("Ruth: looking at life through various lenses: camera, journal, sketches... What you make of it, depends a lot on how you frame it up.")  It is bad enough being redundant, without being repetitive too!

Funny that Epictetus should come up again--Grady Booch quoted Epictetus the other day (4/20/09):

"No man is free, who is not a master of himself."

4/27/09: I was so distracted by the crowd behavior during the Lacy-Zuckerberg interview that at the time, and on subsequent review, I didn't notice the enormous outrage--we were about to find out what Mark Zuckerberg does with his Facebook Vision notebooks when the crowd took over! I suppose it's been revealed since--I'll have to scout. It'd be a real shame if he really does destroy/burn them! I can guess why... but it's a shame nonetheless. So, not only am I redundant, but a lot of the lessons I learned the hard way, are apparently "obvious" to other people. I was fortunate that it was an HP Labs policy that everyone had to keep a lab notebook, or I might not have submitted myself to the discipline of keeping notes--and not just that, but dating them and keeping them in "one place." So I think it is amazing that Mark kept his notebooks without being told to! But... destroying them... that seems like a loss to history... Of course, HP wanted dated records for patent filing purposes. Is Mark thinking about that?

One of the nuggets from Think Better is that it is important to let ideas flow--because the flow makes room for other ideas. Journals play different roles, and one is a personal brainstorming vehicle that allows us to get beyond the obvious that is on the tip of our attentional iceberg, to what lies beneath. I was surprised though, that Hurson seems to be a good visual thinker who is really quite handy at sketching (at least, I assume the artwork in his book is his, since he gives no credit for it), yet he doesn't employ any visual techniques. All his lists are flat text lists; no graphic templates. Is this a considered omission, or NIH, or has he just not encountered Grove, for example? 

4/27/09 Giants Who Reinvent Themselves

Headlined as "IBM's grand plan to save the planet," the Fortune story (April 21) is about IBM reinventing itself--again. Working at the exciting confluence of analytics, architecture/system thinking, and deep technology expertise, IBM is helping companies and agencies tackle demanding "intelligence" problems related to big concerns of our day--global warming, traffic congestion, tracking produce and meat to manage E coli outbreaks, etc. 

4/27/09 Movies and Books Outside the Usual Box

4/27/09 Visualization

This "periodic table" of visualization elements is cool! And this paper is worth a read, especially if you're grappling with cognitive distance--and potential dissonance: "Seeing versus Arguing: The Moderating Role of Collaborative Visualization in Team Knowledge Integration."

More:

4/29/09 Construction Techniques and Architectural Styles

Construction techniques influence architectural styles. Take Gothic:

"The Gothic style brought innovative new construction techniques that allowed churches and other buildings to reach great heights. One important innovation was the use of pointed arches. Earlier Romanesque churches had pointed arches, but builders didn't capitalize on the shape. During the Gothic era, builders discovered that pointed arches would give structures amazing strength and stability.

In Gothic buildings, the weight of the roof was supported by the arches rather than the walls. This meant that walls could be thinner."

"In order to prevent the outward collapse of the arches, Gothic architects began using a revolutionary "flying buttress" system. Freestanding brick or stone supports were attached to the exterior walls by an arch or a half-arch."

-- About.com: Gothic Architecture Pointed arch and Flying buttress

4/30/09 Looks Interesting

And... I should check if we have this (since Dana has read it):

4/30/09 Collaborative Teaming

Thanks to Grady Booch's pointer, I read the transcript of the speech President Obama gave to the National Academy of Sciences. I highly recommend it, as it is another example of the great rhetoric of leader. Interested, I followed up on Obama's speech writers, and there too is a wonderful example--of collaborative teaming and synchronicity. That is what a great leader does--gets brilliant minds engaged in such harmony of purpose as to appear as though the team is working with one supermind--or should that be "über-mind"?

I like the quote Grady used; I just think he missed an opportunity not quoting from the speech, so I'll take it:  

"The very founding of this institution stands as a testament to the restless curiosity, the boundless hope so essential not just to the scientific enterprise but to this experiment we call America. A few months after a devastating defeat at Fredericksburg, before Gettysburg would be won, before Richmond would fall, before the fate of the Union would be at all certain, President Abraham Lincoln signed into law an act creating the National Academy of Sciences.

In the midst of civil war, Lincoln refused to accept that our nation’s sole purpose was mere survival. He created this academy, founding the land grant colleges, and began the work of the transcontinental railroad believing that we must add -- and I quote -- “the fuel of interest to the fire of genius in the discovery of new and useful things.” This is America’s story. Even in the hardest times, against the toughest odds we’ve never given in to pessimism. We’ve never surrendered our fates to chance. We have endured, we have worked hard, we’ve sought out new frontiers.

...

And some truths fill us with awe. Others force us to question long-held views. Science can't answer every question, and indeed, it seems at times the more we plumb the mysteries of the physical world, the more humble we must be. Science cannot supplant our ethics or our values, our principles or our faith. But science can inform those things and help put those values -- these moral sentiments, that faith -- can put those things to work -- to feed a child, or to heal the sick, to be good stewards of this Earth.

We are reminded that with each new discovery and the new power it brings comes new responsibility; that the fragility, the sheer specialness of life requires us to move past our differences and to address our common problems, to endure and continue humanity's strivings for a better world."

-- President Obama, address to the National Academy of Sciences, April 27, 2009

Isn't that great? To direct our attention to the shared history of this nation, a history that has formed our identity as leaders in innovation, science, engineering and medicine. Then to direct our attention at the way this very identity has been eroded by under-resourcing education and research and development. Put like that, after the fact, the design of the speech seems obvious. That is the way it is with the best of designs. They so well fit the context and the need that we can't imagine them having been done any other way. Yet, we all know that at the outset, there must have been so many other designs that could have been settled upon for this speech.

So, in short, this speech is a great example for us. Thanks to Grady for pointing it out.

(I do miss the reflective voice that Grady has transitioned away from in his blog, though I think I understand some of the forces at play. Becoming sensitized to some of the considerations, led to tussles with the lid on this journal...)

 

Feedback: If you want to rave about my journal, I can be reached using the obvious traceinthesand.com handle. If you want to rant, its ruth@traceinthesand.ru.cz. Just kidding, I welcome input, discussion and feedback on any of the topics in this Trace in The Sand Journal, my blog, and the Resources for Architects website, or, for that matter, anything relevant to architects, architecting and architecture! I commit to using what you teach me, to convey it as best I can, help your lessons reach as far as I can spread them. I try to do this ethically, giving you credit whenever I can, but protecting confidentiality as a first priority.  
 

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

Redbud at sunset

 

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

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