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

Archives

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

- Architecture Again

- Context is King

- Origami and UML

- Cutter Report

- Blindingly Obvious

- Constructive Feedback

- Storyboards

- Innovation and Architecture

- Look Where a Wheel Could Be

- Booch is Back

- Trends

- Fish Tales

- Dan Pritchett

- Sound of Cold Water

- Deficit Beyond Astronomical

- Writing vs. reading

- Most Excellent Carrots

 

 

Blogroll

Architecture

- Charlie Alfred

- Todd Biske

- Grady Booch

- Simon Brown

- Adrian Campbell

- Leo de Sousa

- Rob Daigneau

- Louis Dietvorst

- Sharon Evans

- John Evdemon

- Roger Everndon

- Kevin Francis

- Sam Gentile

- Adrian Grigoriu

- Simon Guest

- Todd Hoff

- Paul Homan

- James Hooper

- Alan Inglis

- Steve Jones

- Dave Linthicum

- Sam Lowe

- Anna Liu

- Ruth Malan

- Nick Malik

- Chirag Mehta

- Gabriel Morgan

- Dan Pritchett

- Chris Potts

- Arnon Rotem-Gal-Oz

- Brandon Satrom

- Shaji Sethu

- Leo Shuster

- Collin Smith

- Brian Sondergaard

- Serge Thorn

- Jack van Hoof

- Steve Vinoski

- Mike Walker

- Tim Westbrock

- Rodney Willis

 

Other Software Thought Leaders

- Scott Ambler

- Scott Berkun

- Alistair Cockburn

Innovate/Tech Watch

- Barry Briggs

- Gizmodo

- Dion Hinchcliffe

- Oren Hurvitz

- Diego Rodriguez
- smoothspan

 

Leadership Skills

- Presentation Zen

 

Um... and these
- Nick Carr

- Tom Peters

 

HelpMatch:

- HelpMatch Wiki

- HelpMatch Google Group










 

 

 

Sunset from the Isle of Scalpay, ScotlandSeptember 2008

9/1/08 Your Co-ordinates

This is my software architecture journal, where I keep track of links, ideas, thinking about architects architecting architecture.

If you've acquired a taste for my brand of soporific fix, and you want to cruise by entries from previous months—linked from the sidebar.

9/1/08 Pushing My Thinking

Charlie Alfred kindly responded to this section of my "Architecture, Again" post:

One could say architecture is the set of decisions with highest consequence; those most essential to success and those most culpable for failure. We can come at this from different angles. Grady Booch notes these are the decisions with the highest cost of change. Decisions that took the project in the wrong direction structurally—certainly we mean those. Decisions that relate to "built right," built to meet the challenges of the system when it is fielded and as it evolves, yes. But even more importantly, architectural decisions also encompass those that relate to building the right system in the first place.

Charlie is so thoughtful and so thought provoking that I'm taking the liberty of sharing his response:

"Your statement is correct, of course.  Missing the boat on identifying the problem to be solved is the biggest cardinal sin.  But I would observe that “building the right system in the first place” is one of the fundamental complexities of the deployment environment.  The critical path to success requires understanding the current state of the deployment environment, the desired future state, and the obstacles and risks that threaten the transition.

The threads encompass might involve several of the following:

  • The deployment environment is undergoing significant change (e.g. competitive or market flux).  Value expectations are a moving target.

  • The current deployment environment depends on several legacy systems.  It is not known how long they will be kept and what the replacements might look like.

  • The deployment environment face a variety of different situations.  The system users know what to do, but cannot explain why.

  • There are many different types of deployment environment, and they have different goals or face different pressures from their environment

  • How the new system will be deployed, especially if it will be deployed into a mission critical environment

And this list doesn’t include the work management complexities where the architects/engineers have little subject matter expertise, and may have difficulty understanding the nuances of the problem domain and how they collide with technical concerns."

Charlie Alfred, personal email, 9/1/08

To which I responded:

again to your comments, I have to say 'Amen!" :)  I have been exploring these issues in my paper for Cutter (due 2 weeks ago; .... um, due tomorrow...). Essentially, I'm very much in the camp that we do actually have to "go into the future" and "think around the edges" just enough to think through these deployment scenarios so we don't build production capacity for 40,000 Segways per month when annual sales were something like half that over the first 5 years... or the converse with Twitter...

Again, Charlie came back with a must-share response:

"Yes, there are those who advocate reacting over anticipating.  They claim that there are too many unknowns to anticipate well, and that it costs too much in time and effort to engineer for contingencies.  It is better just to stay nimble and deal with them when they happen. Personally, I think it is a big sliding scale.  For any complexity you face, you have the ability to assess it and choose a response, such as:

  1. This is a threat with great consequences, I must concern myself with how to avoid it or mitigate it

  2. This is a risk with moderate consequence.  It seems reasonably likely to occur, but will be reasonably expensive to avoid.


  3. What is worse:  The Type I error (hoping it won’t occur, but it does) or the Type II error (preparing for it when it doesn’t)?
  4. This is an uncertainty with little or no consequence.  I can wait until it happens and deal with it then.

Typically, nobody would argue with reacting over anticipating for Category #3.  “Should I have the user enter city, state, and zip or just the zip and lookup city and state?”  The cost to do it one way or the other is negligible, and so is the impact.  Pick one, and change your mind later.  This is not an architectural decision.

The problem with Category #3 complexities is that engineers, especially ones who face a large conceptual distance between themselves and the problem domain, are seduced by abstraction and generalization.  “I don’t know what might happen in the future, so I will just design for the most general case.”  Do this 100 times and the cost escalates.  The agile advocates are absolutely correct about this.

On the other hand, Category #1 decisions are automatic.  You simply cannot risk catastrophic failure, no matter how agile you think you are.  The online web sites who were victimized by hackers and compromised customer confidential credit card information failed to think this one through.

Category #2 is the difficult category.  Sometimes it is right to accept the risk and react, sometimes it is better to anticipate and mitigate.  But the critical thing is that you must assess the risk and make an explicit decision.  In my book, closing your eyes and hoping for the best is not a responsible action."

Charlie Alfred, personal email, 9/1/08

9/1/08 Architecture, Again—Again

Architecture decisions are those with the greatest consequence if we get them wrong. These include early decisions which gate or constrain all subsequent decisions. Architecture decisions are the decisions we need to think most carefully about, because

  • they have strategic impact: they impact our value proposition and competitive position, or

  • significant structural impact and bear high cost of change.

These include scoping decisions (what value propositions to offer, what capabilities to build to deliver these value propositions), staging decisions (what decisions to make early; what capabilities to build in what timeframes), high-level system decomposition/composition decisions, and architectural mechanism design (addressing architecturally significant cross-cutting concerns). They also include architecture strategies, designed to address architectural challenges and risk.

9/5/08 Context is King, and Other Axioms

I've by no means read all of the 97 Axioms every software architect should know, but of those I've read so far, Context is King is my favorite. Still, with context and communication king, who is queen? Diversity?

Oh, and I do like Mark Richard's tradeoff story.

Many of these axioms use stories to make their point. Context may be king, but stories rule!  Let that be know as Ruth's axiom.

9/5/08 My Paper (or at least my confidence) Needs Your Help

Stories rule. So, anyone want to read my report for Cutter? I only want enthusiastic feedback, but if it doesn't fly I guess I should know that... So, if you're willing to read 13,000 words (ignoring footnotes) and give me feedback before the end of this weekend, email me (ruth at traceinthesand.com). If you've been following along in my journal, you'll have a strong sense of déjà vu. Still, if you think the paper works, I'd like to hear from you as I'd be excited to expand it into the "Getting Past But" book I threatened back in February, and outlined last month. Yes, 13,000 words seems so vastly many, yet not nearly enough to say what wants to be said! The question is, do they want to be read?

Well, anyway, I tried to write something that would excite and inspire architects as innovators, but also empower them by providing practical tools. It reaps key themes and even words from this journal (hence the déjà vu), but is (hopefully) more cohesive and better organized. I suspect it is either really great or really bad, but I'm so close to it I can't tell! My self-confidence, usually reasonably robust, is somewhat a-teeter. Dana says reading the paper is like going on a journey. I hope that means of discovery, and isn't just a reference to the length...

9/5/08 Origami and the UML

Origami is an age-old craft, but it was revolutionized by the creation of a design language: according to Robert Lang “The modern art form was born in the 20th century when a Japanese artist named Akira Yoshizawa started creating new figures of artistic beauty that inspired other origami artists to expand their horizons. Yoshizawa also created an instructional language that then enabled them to share their creations and build off of each others’ work." Now complexity that would have been incomprehensible is manageable, and ever more innovative designs are being created to astonish and amaze us—the video of Robert Lang talking about and demonstrating his craft at TED is wonderful!

Software design languages like the UML have also played their part in making design advances, and our field has seen dramatic increases in system complexity, in part because the design language gives designers a means to visualize, explore and communicate design elements (separating design decisions from implementation details), and in part because design knowledge can be captured and shared, in particular in the form of patterns. In software, patterns have been formalized to mean not just the design elements in structural and behavioral model form, but also a clear characterization of the problem being addressed, and the context in which the solution is a proven good fit to the problem.

A good while back, Grady Booch touched on similar points, referencing dance:

"It seems to me that there's a curious relationship between dance and software architecture: in both disciplines, there are only a limited number of patterns available, each genre assembles those patterns in specific ways that define a particular genre, and furthermore, most knowledge is passed on through tribal memory, from one dancer or architect to another. In dance, by the way, some attempts have been made to define a graphical notation (labanotation) for describing dance movements, just as we have the UML for visualizing, specifying, constructing, and documenting software-intensive systems."

Grady Booch, blog entry October 2, 2005

Grady Booch was one of the key figures who fathered our software design field in much the same way that Yoshizawa did, by giving design a language.

9/5/08 Red Cross Appeal for Help

Red Cross is appealing for donations. In the wake of summer flooding, the Red Cross coffers are apparently empty. They need our help, so that can in turn help with Gustaf and Hanna relief.

9/6/08 Cutter Report

Charlie Alfred, Dana and Ryan are my heroes—all three have given me great input and assistance on the Cutter Report. Ryan (you no doubt remember he is 10) is working on taking out redundancy, and he is a great micro-level editor. He'll probably be a great macro-level editor too, but he's still making his way through the paper. Dana got lost on the journey and asked for a roadmap and I think that will prove to be a critical addition to the paper. And Charlie just blew me away—in one day, when he presumably also spent some time actually living his family life, he not only read the report but found gaps and issues and didn't criticize but rather made very valuable suggestions including really neat stories and references! Of course, I have to take more than 1200 words out but, as I said, Ryan is working on that. Between Ryan, Dana and Charlie, if this paper doesn't work, I have only myself to blame! Thanks guys!

Here's the summary of "Getting Past "But": Finding Opportunity and Making it Happen":

Innovation and Agile Architecture Exec report Summary

9/7/08 Cutter Report

The "Getting Past But" paper will still be under my control for a short while longer, in case you're thinking about joining Charlie, Dana and Ryan in my gallery of heroes working on pounding it into shape. Also, I'd like some "kudos" to use in case the editor is anxious about the fit and form of this report, with senior architects and technical managers in the target audience. Plumping up my ego is always good in my book (it has been an inordinately long time since I got an actual, direct compliment on my work, so any excess of ego I have is entirely self-generated), but I'm after some support to allay any concern the Cutter editor might have. Perhaps I am being too anxious, for the paper should speak for itself. But the paper takes some risks, as is proper for anything associated with innovation, but not everyone is savvy to that. Naturally, I think it is extremely artful, and full of art--the wheel is used as a story, as a metaphor, and as an organizing principle throughout. But as I said, I'm too close to it, and I'm confident and terrified by turns!

9/9/08 Blindingly Obvious

I just read Eric Jain's review of Collaboration Explained by Jean Tabaka, in which he says:

"Like most books on these kinds of topics, this book contains it's share of the blindingly obvious (meetings must have a clear agenda, people must be respectful of each other's opinions etc) and anecdotes that don't prove anything (except that the author has real world experience)."

Since I haven't read the book, my reaction isn't at all to his review per se. It is to the question it raises in my own mind about my paper for Cutter (and this journal). That confidence-and-terror-by-turns thing persists! But then I remind myself that actual behavior predicates the need, if not for the lesson, then for the reminder to heed the lesson. Where we shine the sharp light of our attention, throws what we are not paying attention to into greater darkness. So my job is to come along and shine a light where a light is needed. Tell people to brush their teeth (I'm alluding to a Derek Coleman anecdote--near the middle of this piece).  

... almost 10pm... my kids! I have to go tell them to brush their teeth!

9/10/08 Constructive Feedback

I'm a great believer in constructive feedback. Absolutely. As long as someone else is getting it. (grin)

I was kindly advised to ditch my sketches in the Cutter Report. I've plucked the dagger bravely from my heart, and stumbled through the day... Oh, I'm still kidding!

Anyway, I'd planned to redraw most of them, but I think I'll stay out on a limb on this one and retain the sketches (redrawn). Dan Roam is getting a lot of attention for bringing hand-rendered sketches (of the kind he, you, and I can draw) into the group mind-space. But there are icons that went before Dan Roam. I've long been a proponent of the work of David Sibbet and his team at Grove. They have been teaching the value of the visual image in group work for a long time--I took their graphical facilitation training in the mid-90's, and Dave had already been at it for a long time at that point. Ok, don't blame Grove, they do help but they can't create miracles of transformation in talent--only miracles in transformation in audacity in drawing anyway. So I've come to learn the power of drawing to facilitate group thought, and frankly, my lack of skill is liberating because nobody finds my bar too high!

I love my software!So, audacious as I am, I'm going with my instincts on this. You know, doing my part for the world demonstrating that polish isn't always the best communication medium. Don't get me wrong, I've long been a very strong advocate of polish. I even make a work of art of the way I stack my dishwasher. I try to imbue our staff with a fine sense of attention to detail, even down to the way we tape our boxes of course materials (we have a mini-factory going, with licensed materials shipping around the globe). So when I use a sketch, I am doing so to achieve something that goes beyond "cute." I'm trying to demonstrate the value of visual expression.

For instance, what does the sketch on the right bring to mind? For me, it's "when last did I feel like that about a piece of software?" I'm kidding--I've had affairs with several Microsoft and Adobe products, but of course, I can't name names (not even if they paid me ... to). I'd say Intuit too, but there it's a love-hate thing because Uncle Sam is involved.

Elephant doo dooAh, base humor. And it hit a still lower point today... I was reacting to the notion that with all the focus on DO DO DO too much do do is produced. Which brings me back full circle to the idea that launched the whole getting past but notion. It all began with this image of the architect trying to push the elephant (organization) from behind, and realizing that when we don't let the architect get out front and lead, we may as well give the architect a shovel because all he can do at that point is damage control.

None of that made it into the Cutter report, so, you see, I do show some restraint.

But not much. At least, ... not enough?

I'm going to have to create an undercover-undercover version of this journal!

9/10/08 Storyboards

I think storyboards are a powerful way to develop system concepts without developing the system to develop the concept. So I was excited to stumble on Toon Boom and their storyboard product. Think they'd give me a copy to evaluate, so I can see if it's worth marketing to system designers and architects??? The latest Harvard Business Review has an article about Pixar's creative process that is an interesting read. The Animation Archive is a great resource. Like--this one could be used for your next product concept as is!

Chuckle.

The last time I cruised the ASIFA Animation Archive I stumbled on a description of the early Disney storyboard creation process. I couldn't find it again, but did find this.

If you think I'm kidding about all this, stop by an elementary classroom and see what the kids are doing with GIMP. Get them to storyboard and animate your product concept before you show it to your CIO or R&D manager.

Besides, if I can be audacious enough to pitch a children's story to architects, why not storyboards, and why not take them all the way to animated cartoons?? 

9/11/08 Getting Past But Innovation and Architecture Report

After all my trepidation, the Cutter editors have been very kind to me--"I love your Report!," "You did a fabulous job on your report!," etc. So the ego massage I needed came from the kind ladies at Cutter. But, if you were just waiting for the ladies to go first, by all means chime in now with your words of gratitude at my joy-in-work affirming, career/life-changing paper (if it didn't change your career, then it should probably change mine). Because, as always, I set out to inspire and enable; to set a vision for what is possible, and offer practical and effective tools to draw in the talent that makes the big dream possible. (I have a geeks love of word play and that "draw," in the light of my report, has reverberations of meaning.)

Yes, I leveraged the toolkit I practice with architecture teams, in workshops and in this journal, but in the process of pulling the pieces together in just this way, I learned new relationships, saw new dimensions, found new meaning. I'm excited to work on a book that puts back in all the words I had to take out to get down to only 1,000 words above the Cutter limit! And I'd get to add in stories and recommendations from Charlie Alfred that I couldn't do full justice to in the report version. So my next mission is to get a publisher to contract for the book, and I'll use the Cutter report and any favorable words from anyone who cares to supply their recommendation and name/position as a backing to my book proposal. 

Here's an overview of the report:

Innovation is seen as a key to the competitive differentiation equation, and technology factors strongly into that equation. In this report, we explore the “fuzzy front end” of system development and renewal projects. We present our circles of innovation model, making the case that to find differentiating opportunities to create value, we need insight into customer/user needs, insight into what technology makes possible, and insight into our business positioning and direction relative to competitors and the value network. Next, we present a story that with astonishing and charming acuity conveys key principles of the process of innovation, and debrief the lessons from the story relating them to the innovation-in-system-development context.

In the second half of the report, we share pragmatic practices and tools for enhancing the effectiveness of system concept generation, elaboration and refinement that are at the heart of the innovation process. The process pulses through cycles of divergence (opportunity generation, problem finding and solution finding), and convergence (decision making and alignment). The tools we emphasize are those that foster ideation while creating an aligned team that balances exigency with just enough upfront design to orchestrate the socio-technical process of creating the myriad innovations that contribute to the overarching innovation vision.   

We will post a link to the report once Cutter has it all wrapped up (next week).

9/13/08 Look Where a Wheel Could Be, and Where it Could Not Possibly Be

Dana's been back on a code kick, and writing on top of a framework where the kludginess bleeds out at the interfaces, he's had to keep going back to this key lesson from The Wheel: look where the solution could be, and where is could not possibly be. Figure out what you expect, then put that explicitly aside and look at what all your good sense and experience tells you could not possibly work!

And you thought The Wheel was just about vision and teaming. Ha!

"There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them!"

Richard Feynman

9/14/08 Booch is Back

I mentioned last month I was concerned about the then 2 month gap in Grady Booch's blog, but at that point surmised that no news was good news. I gather that's not true; at least, not true for Grady. In his complexity slideset, Charlie Alfred used a photo of trees grown all woven together to illustrate interdependency. I just loved that image because in systems and in relationships, the interdependencies cause both entities to take their weathering together--to be shaped together and by each other. So change is difficult. In social systems, and in technical systems.

The whole notion of community is shifting, because we're integrating online community so quickly into our experience. What does "community" mean when you encounter members of your online community more intimately than your neighbors?! There is that "mind blind" failure of social restraint that Goleman and Shirky talk about. Ok, they're talking about web rage, but the other side of the phenomenon is web intimacy, or sharing of thoughts, hopes, identity. Like, if you've read my journal for a while, you know me a lot better than my neighbors do, and probably better than anyone outside my immediate family. If something horrible happened to me, you'd probably care, not just for what you'd miss, but because of the impact on me.

One of the things I like about Grady is that he "shows up" as himself in his blog. Himself, not just a cardboard facade of a blogger, but a real person with rough edges and delicate, tender places in himself--the things he cherishes about himself, others, life. Actually, he used to do that more circa 2004-2006'ish, and I liked his blog even more then because we got to follow more closely on his journey, where he traveled in his investigation of architecture, technology, life. The evident pleasure he's taken in his journey is life-affirming--the redemptive nature of creative work is something we learn not just for ourselves but from the people who exemplify that joy in man's desiring, that joy in man's aspiring.

In IBM, the architecture community, and the software community more generally, Grady is a leader. In person, leaders who are full people, not unidimensional projections, are more compelling--resonant. Apparently this is also true in the extended networked community that is supported by blogs and social networking forums.

So I say all that by way of explaining I care that Grady has been facing a situation that is life-changing hard for him. From the perspective of community, that is not odd. Communities care about their leaders.

Dana was telling me about a Stafford Beer book (that I haven't read but which we apparently have--frankly, I have no idea how many thousands of books we have collected across the expanse of two adults and two children's acquisitive cognitive journeys), in which Beer used colored paper to code the content--a color for personal stuff like experiences, thoughts, poetry; a different color for formal papers; and so forth. (My encounters with Beer have been as an operations researcher and systems thinker). There is an inclination to tell one's story, and an inclination to read the story of interesting people; wide awake, exploratory people.

Speaking of acquisitive cognitive journeys, I realized that Ryan was tapped out on ichthyology, knowing more already than sanctified experts in the field. He has always loved history, and has a boy's interest in the powerful (dinosaurs, trains, planes, volcanoes, tornados, presidents) and warlike. So, against all my pink peace-loving inclinations, I bought him a dozen books on the wars of American history. And he is like a kitten in a bed of catnip! Gamboling his way through history books written for adults--not because of the content, but because of the joy of learning.    

And speaking of Ryan (10), he hit a milestone yesterday, for it was the first time he beat Dana at something physical. It was Ryan's first 5km competitive run, and he beat Dana by a minute! He was the first kid in, and beat many hundreds of adults too. Alternately put, only 102 adults beat him. He's a small kid so at a disadvantage on sprints, but he sure comes into his own over a distance. In a list of "rules of household conduct" Ryan and Sara put together a few months ago, they wrote "Adults should let children win." Now we enter a new era; one in which we have to work hard to barely keep up! Their last rule? "Do not disable lavatory smoke detectors!" It was a joke from our young world-travelers but... I guess, we're not so far off needing that one!

9/14/08 Trends to Put on the Radar

9/15/08 Storks, Fish, and The Timeless Way of Building

Commenting on the Getting Past But paper, Charlie Alfred shared this story:

“We should try to think the way a stork would think.”   Bill Stinnett’s dad made a similar point to Bill when he was 12, that stuck with Bill his entire life and helped to make him SAP America’s leading salesperson.  Bill wrote about it in his book Think Like Your Customer, one of the best books I have read in the past couple of years.  Bill and his father used to go fishing.  Young Bill never caught anything, but his father always seemed to catch the limit.  When Bill asked his father for advice, he replied, “Bill, if you want to catch fish, then you have to start thinking like a fish thinks.”  They prefer shade to sun (no eyelids), warm currents to cold, and grassy areas to open waters.

Kristen Sanderson also reminded me that Christopher Alexander makes similar points about putting oneself in the customer's context in The Timeless Way of Building (and likewise in The Nature of Order series).

The thing that I so like about The Wheel, is that it makes every point I'd want to be sure to make about innovation, but it does so in this completely unpreachy way because it has no intention of teaching adults these lessons; it is just a children's story! It was first copyrighted in 1954. The author is long dead. And yet it beautifully addresses all the key lessons of a collaborative innovation process. Diversity. System thinking. Empathy. Overcoming resistance. Dynamic teaming. Assumptions gate possibility. Look where the answer could be and where it "could not" be. The transformative power of alignment, of motivation to achieve a shared dream. On and on. It is like the Madison story we tell, in that it is so rich with lessons that I keep discovering more.

As adults, the child-like quality of wonder, and believing we can do remarkable things, is in danger of being stifled by the silt of experience, the sediment of setbacks, and we hit the wall of "but." The Wheel sows the seeds of the idea that we can do it, we can dream a big dream together, break it into doable chunks, and with hard work and some luck, make it real. What if Michael Phelps gave in, what if he had coasted in rather than putting one more butterfly stroke out there? He wouldn't have made 8 golds, broken all the records. But he had the big dream, he worked hard, he never gave up, and Destiny capped all his work and talent by serving him one great stroke of luck!  

But the seed of an idea, planted in the silt of experience, watered by the hope of the big dream, flourishes. Sorry, couldn't resist taking the metaphor all the way. It is interesting to see how many of the greats of science and engineering wrote poetry (Feynman and Beer being two that I have mentioned just this month). I say that in case you were just shrugging me off as irrelevant. Grin.

I'll get you to read The Wheel yet, by golly! Wink. I'm only sorry that my influence meter (Amazon referral tracking) doesn't work through the Cutter paper. It was kind of fun to see how terribly unsuccessful I was at getting people to read The Wheel--I don't need my ego reigned in, since my super-ego is more brutal even than left-of-left-brain software engineers reacting to my right-left bridging style (and believe me, I've been brutalized aplenty--like, um, twice. But that was enough!).

Speaking of being brutalized, I had this paragraph in the Cutter report:

"We need to think in terms of multifunctional teams who are innovation and design centers. Instead, we typically have user interface folk who drive “user experience,” we have requirements or business analysts who drive “requirements capture” (as if they’re running around and we just have to corral them), and we have software architects who wear beepers and are the second line of defense when the ops people can’t put out on-the-line fires. Like these are all separable concerns. Different beasts. For beasts we make them."

The Cutter copy-editor didn't like "For beasts we make them." so that line is zapped. I'm grief-stricken at the loss. One of the greatest insights in software, killed. Dead. Gone.

Next time I contract for any of my writing, I'm going to insist that I have ultimate authority, that unless something is wrong, if it could go either way, it goes my way. I assume an intelligent audience. Sometimes I might challenge their faculties understanding the layers of meaning I can stack up in just one sentence, but the reward is worth it. No????

"For beasts we make them." That is giving people power back. First, to see them as beasts. Then to see them as beasts we created. Then to not do that! The line is important. Maybe I should tell Cutter that... see if they'll put it back in before it is too late... Tick tick...I love my architect

9/15/08 Dan Prichett

For a while now, I've been meaning to say that although I'm sure it was good for Dan and for eBay to have Dan dug down deep in code and not blogging for several months, I'm sure glad he's back! Dan's blog is exemplary! I love posts like the most recent one exploring "free energy" -- both for its immediate message, and for Dan's illustration of the point I was trying to make last month in my "Share your knowledge" piece.   

9/18/08 No Music, only the Sound of Cold Water

In VAP, we emphasize bringing in fresh perspective early, and then often, during the cycles that iterate between system concept elaboration and user experience design (requirements) and architectural design. Criticism: Pouring cold water on the idea (or architecture in this case)Early on, you really want to bring in "friends of the architecture," because cold water too early can be hard to recover from. The cold water may be well-intended, but innovation is about problem seeking as much if not more than it is about problem solving (because we have to find the problems to solve them). So we expect to find problems! But we want to do so without eroding the energy of the team.

Feedback is important to improvement, essential even. But careless negative feedback is damaging--maybe a little, but maybe a lot. So in setting up validation meetings (both formal and informal) be careful to set the expectation of goodwill and collaboration, and don't invite the perpetual wet blanket to early iterations when momentum could be damped; also be careful about those whose turf is threatened and so defensive. If you can work with them offline and bring them around, getting their skin in the game, then great. But be wary about exposing your team and sponsors to an early dousing of cold water.

For those who are called on to give feedback, there are cautions too. Architects who are held in high regard, carry frigid water when it comes to negative feedback, in that the impact is the more chilling because it is coming from someone that matters in that social context. Feedback, and how you give it, is a powerful tool. It can be used to create a course correction. Dana Bredemeyer is a great believer in using a rapport break as a tool, advisedly and only where it is needed, then to rebuild a stronger bond with the terms of engagement more clearly delineated thereafter. But burn a bridge, and it will take you a lot more effort to rebuild, than it took you to destroy it. A rapport break is certainly not the same thing as being mean, and should not be done in anger or from a defensive position.

Also, I should add, Dana is the kind of person about whom clients say "our architects loved him; so did my husband" (in that case, they had a get-together in the evening with spouses along). Dana laughs easily at everyone's jokes, is sincerely appreciative and positive but candid in a way that doesn't erode confidence, and his interests and experiences are so broad, that he almost without exception has some way to relate to individuals on a personal level. So, when he uses rapport break as a tool, he is coming at it from a very strong base from which to rebuild. 

As we recognize that the social side of socio-technical system development has it's own set of intricate tools, we can work to hone them, and become better at choosing them when they fit the need. Udi Dahan (97 Axioms) recommends standing to talk in a meeting, to show through body language you're in command. I would take that under advisement, and use it with discretion because there are times to direct and times to show through your expression, including your body language, that you are taking input, collaborating. But first to recognize that system development with and through people takes skills we can come to appreciate and develop, then to work on doing so.

9/21/08 Deficit Beyond Astronomical

Richard Feynman purportedly said:

"There are 1011 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers."

Today, the debt is bounding upwards at a rate of $1.84 billion per day, and will soon hit 97 times the number of stars in the galaxy! $9,700,000,000,000 is a big number! (An increase of $4 Trillion since Bush took office) There's a neat TED talk on visualizing numbers (Chris Jordan). I think this is something for business intelligence architects to think about, because if we want information to change behavior (so the organization behaves intelligently), we need better ways to make information compelling. Going back to the deficit, which compels change: the Treasury presentation of the national debt, or the national debt expressed on a per person basis? Spread equally over the current estimated population, my kids each already owe $31,728.00 and they're not even out of elementary school!

9/21/08 Writing Versus Reading

A while back I said I wanted to extend the 'Getting Past "But"' Innovation and Architecture Executive Report into a book. Bad idea! I am so utterly sick of rereading my own writing (the downside of well-intentioned attempts to rub down some of my edge). On the upside, as much as I complain about the small things, the Cutter editors were extremely supportive about the big things. And even some small things. They nixed my "Girl Scout moment" but they left in my Monty Python reference (to Month Python and the Holy Grail)--yes, I reused a line from last month's journaling; couldn't resist! I saw that Monty Python sketch as an undergrad, and still remember it vividly. It is one of those things that gets worse with age; my age, that is. But it is a cultural commentary.

Anyhow, for the record, I had said:

This is not about getting into a cozy circle around a campfire and singing Kumbaya, or some such Girl Scout moment.  If we are creating a complex system that requires expertise that is distributed in different people’s heads, we need to create a shared understanding of what the system is.

They removed the phrase "or some such Girl Scout moment." I guess they didn't like my pink allusion, but my intent was to counter the notion that such a concern is pink to begin with. You know my mantra, system design is socio-technical work. The hard stuff is too often the social stuff, because we are steeped in dealing with the hard technical stuff, but until we became architects, we didn't have to sweat the shared understanding distributed in different heads stuff. But simply working with other people, modeling with them, getting their ideas into the mix, brings them into the picture. Not all the time, but at critical points in time, when they have something to add, if only a fresh pair of eyes and an active mind.

Writing is a funny thing. When I wrote too many words, I told the Cutter team each word was like a brain child and I hated to kill any of them. Of course, some may think my report is over-populated and could stand a whole lot of culling. But even though I mainly use words everyone else uses (with some exceptions, like foment), each word feels important. That said, I just know that if I had a week to let it lie fallow, I'd find a hundred things to take out... and two hundred things to add!

9/25/08 Most Excellent Carrots

This from Tim M. on his sign-up on the Resources for Software Architects mailing list:

"Excellent Website!"

Tim, thank you for providing a "feedback loop" on one of the big accomplishments of the last ten years of my life! 

Pausch argues that hearing what other people say about you and your work is crucial to success and happiness. Because this is what you get: "a feedback loop for life."'

Jesse Kornbluth, who interviewed Randy Pausch for Reader's Digest in February

We will at least have a reason to send out a mailing list update soon—announcing the URL for the 'Getting Past "But"' paper, and reminding folk that we have only 1 place left open in the Software Architecture Workshop in Indianapolis in October, but several places in the EA workshop in November as well as the Architectural Leadership and Other Skills: The Role of the Architect workshop coming up in December.

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.
 

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