Trace in the Sand Software Architecture Journal

Some Aussie bloggers started a "software super villain" cartoon thing, which, with some attention, could become something (a creative way to vent, at least). So here's my 2 minute hit:

In "collaboration" with Nick Malik (should I tell Nick?), I created the "Perpetual Critic" villain for the Software Super Villains series:

perpetual critic software villain

"Good architects do more than 'seagull' the project (Fly in, make a lot of noise, crap all over everything, and fly off.)"

Nick Malik, Don't walk in with a problem until you have a solution, Nov 2006

Along the same lines, there's the "Bucket of Cold Water" guy (a.k.a. the "wet blanket"):

bucket of cold water software villain

8/3/08 Architects In Myth and Legend

architects on pedestal

Scott Ambler says in common practice, architects place themselves on pedestals. I don't know any of those architects, which obviously means I only know uncommon architectsall 3,581 of them! Anyway, I created this "architects in myth and legend" piece depicting the self-aggrandizing architect. This obviously alludes to the "emperor has no clothes" story, and is a reference to Mark Mullin's concern about the architect who doesn't code.

architecture astronauts

Along the same lines, Joel of Joel on Software fame has created the mythical Architecture Astronauts, and I simply illustrated the concept. Oh, I do know that you're not an architecture astronaut! Of course not. But how many developers have put architecture and astronaut together into a binding that won't uncouple, no matter what evidence you provide to the contrary? It is a harmful image, and it panders to the worst stereotyping tendencies in our field. So, apologies to archman! We need to be careful about the myths we cast around the role of the architect. Remember, these are not issues with architects in common practice. They are aberrations we need to avoid, though.

I still have to scan in my "ivory tower architect" take-off of Rapunzel, and super-archman. It's all very well sketching these things when I'm in a holding pattern somewhere, but it's the scanning part that takes its time toll. I could delegate that, but then I'd have to tell my assistant I sketch cartoons during off moments... I'd lose all my authority at that point! Of course, I have no credibility with you, so I'm not worried about losing it. Grin.

But of course, there's a meta-message. I've mentioned the "Leadership as Performance Art" course, and obviously I think there is something to the notion that if we play the role of leader, we have to accept it comes with performance demandsyes, job performance but also performance in the theatrical sense. This goes for me too, and these demands on me are 360° tough! Our clients give us some of their best men and women for several days, and I have to give their top talent value. That's a tall orderI'm that girl who grew up barefoot-free in Africa, after all! So, I have to "stand and deliver," but any chuckle that carries insight along with it is a double win. So it is important for me to stretch, stretch, stretch in every dimension. Practicing sketching, finding funny snippets to sketch and make a point with humorall these things are actually important. They are important to what I do. But I believe that by doing them better, I become a better role model for architects. If I can take these risks to be more personable, less introverted and shy, then others can too. And it is important if we want to lead, to be able to get and hold attention, and to develop, despite our inadequacies, respect for the strengths we do have. Isle of Scalpay off Skye

8/4/08 In a Vacation Mood

Archman on summer break

August is a slower month, with many in the US and Europe on vacation. Of course, we took ours alreadythe picture on the right is one of my favorite photos of Sara; it was taken on the mountain that is the Isle of Scalpay (off the Isle of Skye), Scotland in early June. As long as you promise not to book Keeper's Cottage when we want it, I'll highly recommend it!

And the photo below is one Dana took when he went mountain biking last Sundayhe was working in Salt Lake City this past week and went out on an early flight so he could enjoy real mountains. These woods look like something right out of Narnia; tree people, each one a character. Dana tells his workshop groups when he gets to the gates of Heaven, the trees will send him back! Visual Architecting, wall papering walls with the system models, does sacrifice trees to the creation of team mindshare. Patagonia's Yvon Choinard, and others, suggests penance as atonement for our impact on the planet. I need to look into rainforest protection trusts to donate to! mountain bike trail SLC Utah

Dana came back remarking on the wonderful culture and the climate of the group he was working with in SLC, and I pointed out that they have an unusually high proportion of women. He hadn't really grokked this until I pointed it out, but then he realized that yes, the women were creating this sense of family, of meaning in the group context, that made a big difference to the group energy. Of course, I can say all this with the utmost respect, because I am so not that sort of woman. I wasn't in the right line when all those social skills were being handed out! I have to consciously work at any degree of social grace.

Indeed, I invented a term to describe myself: I'm a devote introvert. It lets me get a lot of work done! Yes, I have to become extraverted to get work done in teams and workshops, but then at the end of a consulting or workshop day, I turn turtle. [I mean, go into my shell, but it is also a sailing term I learned last week when Ryan was at sailing camp. demonstrating not turning turtle At the end of the week, Ryan (10) took his sister (8), his dad (not telling) and his grandpa (over 80) sailing, and Ryan was the only one in the boat with any sailing experience (Dana's done the big yacht thing, but that's very different to the small sailing craft thing). Ryan did really well. So did his crewthey learned about jibs and booms real-time. He handled crossing the paths of the super-aggressive power boats out on Lake Monroe, turning around, and never turned turtle, nor even capsized.]

8/4/08 Share Your Knowledge

I was thinking about two of the points that Randy Pausch makes in The Last Lecture. On the one hand, there's quoting others because their words carry so much more weight than our own:

"if you dispense your own wisdom, others often dismiss it; if you offer wisdom from a third party, it seems less arrogant and more acceptable." Randy Pausch, The Last Lecture, 2008

On the other hand, there's the credibility that comes from being recognized by othersso that our own words start to carry more weight. Randy recognized that The Last Lecture would have more powerful influence on his children if it was a book that others admired, than if it was a private counsel written just for his children.

This is a very savvy insight, and it speaks to why it is so important to freely share our wisdom in our architecture documents. The insights, the experiences, the considerations weighed, the pitfalls avoided, these are what makes the documents interesting and valuable. And as smart people find the architecture documents valuable and talk about them, they start the social epidemic of personal recommendations through the technical network. This how our ideas gain organically growing influence without resorting to "big stick" authoritarian demands that people read the documents because it is "their job."

Freely sharing your hard-won insights and experience may seem counter-intuitivelike if I talk about and write down all I know, I become redundant. But that's not the case. The more you share, the more you're in demand. First, you are more useful to others if it is clear that you are fully vested in enabling them, not just serving yourself! Second, your credibility goes up because others have more evidence of your experience and talent. Moreover, let's face it, what you are sharing, even when you share all you can think of, is only a part of your value. The bigger part is how you respond to new problems and new permutations of problems. Your particular blend of experience and talent makes you uniquely able to problem solve, and problems morph. Make your architecture come alive The way you shape and define the problem is itself a unique skill. And the way you address it, the way you bring your expertise and that of others into the problem solving process is unique.

Making your architecture come alive takes a wonderful concoction of visual models, descriptions, explanations, considerations that connect the dots to stakeholder goals and to experience, even stories and examples that teach. It takes a mix of presentation styles, including formal and informal documents, presentations, discussions space on the project wiki, whiteboards or posters (again formal and informal), and conversations, conversations, conversations. Strategic conversations, and just walking the talk, and listening, listening, listening, absorbing and changing, showing by example, and more...

I don't mean making the core architecture document heavy as a brick! The US Constitution serves us well here--4 pages, elegantly minimalist. And supported by the 85 Federalist Papers. These were much like technical white papers that took some current concern with the status quo, and explored how the architecture addresses it. Today, we could do this with a blog or project wiki.

I try to live this advice, sharing freely the insights that I wrestle from my experience, my analysis, my thought journeys and my collaboration with other people's experience, whether it is directly on projects or indirectly in my broad and voracious reading. Two and a half years of this journal, and ten years of the Bredemeyer site, lay testament to this free sharingwhich you may feel, is arguably too freely shared, if word count is the measure! But it should certainly be clear that I am fully vested in enabling others!

8/4/08 The Tiger has Designs

Other countries are paying concerted attention to developing excellence in design. Take India for example. If we think innovation will protect our position in the global economy, we need to work on, and invest in, fostering innovation and design excellence.

8/7/08 Art and Fear

A Jeff Atwood blog post drew my attention to the book Art and Fear by David Bayles and Ted Orland. I don't want to repeat what Jeff said, so to understand my comments, please read his post first. I think it contains a great lesson. But it could be taken too far. The pursuit of perfection, or even of creating something that is really, really great, can be paralyzing. If you don't produce, you have nothing to learn from and nothing to show for your time, nothing tangible to be judged and improved upon. On the other hand, just writing code to pump out quantity, is also a path fraught with waste. The point is not that everyone in the quantity group produced high quality, but only that those who produced high quality came from the group with more experiencethe quantity group. Life, architecture, system development, are not about all or nothing. There is a danger to the pursuit of sublime perfection at the expense of producing practical results. And there is a danger to the pursuit of quantity without attention to quality. Especially as complexitysocial and technicalgoes up. Yes, experience mattersa great deal! Yes, tangible progress matters. Yes, evolutionary development towards a better adapted system matters. And yes, architecture and design matters too!

As a teaser, this post contains excerpts from Art and Fear. In particular, this line got my attention:

The lesson here is simply that courting approval, even that of peers, puts a dangerous amount of power in the hands of the audience.

I think that is behavior-changingly profound! We seek out recognition and approval, thinking that will charge our energyif we get it, we get that positive feedback loop on life that Randy Pausch talks about. But it is a gamble, for by courting approval we risk indifference, or worse, disapproval. So we should understand the gamble, and resist courting approval if the downside will put our passion or our project at risk at some premature juncture.

8/7/08 Workshops

There are only 3 places left open in the Software Architecture Workshop in Indy in October! But I've pushed the Role workshop that was slated for September out to December to allow more folk a chance to find out about it. Still, I have to wonder if we should instead just schedule another Software Architecture Workshop in that slot... One-stop-shopping for the broad slate of architect soft skills seems not to be in high demand this summer...

08/08/08 Nothing to say; just enjoying the date!

08/09/08 Documenting and Architecture

I stumbled on Gavin Terrill's blog post titled Does documenting your architecture make it high quality? and it deserves comment. Those who resist documenting their architecture are not usually so frankGavin ranks documentation with filling out time sheets! I've seen the change constant invoked for not commenting code, too, along with the argument that the code should be humanly readable and understandable without relying on comments. (Commentary on comments is blogged here, and here, and here and here). I agree that making the code lucid, applying refactoring principles and memes to do so, is sound practice, absolutely to be encouraged.

The trouble is, the code doesn't explain why; the processor doesn't need to know why. (That is what distinguishes a computer from a two year old!) What are the assumptions, constraints and requirements, the experiences, that made this choice of approach make sense? And the code doesn't provide the big picture view, the relationships, and the web of decisions that together deliver on the objectives of a design theme or cross cutting concern (like scalability). Programming languages are already human-readable. Not by everyone, but not everyone understands English either! A poem shouldn't require a prose narrative to understand it, but a narrative may add insight into what the poet was thinking, what the poet intended. When we read a piece of code, we can understand it in a local sense. But we can't see the performance implications, duplication and (in)consistency with other parts of the system, and so on, and on. We can't see the reasoning that made writing the code this way make sense. If we are asked to provide our reasoning, by implication we're being asked to think about alternatives. Sometimes that matters. And sometimes banging out anything that just works is good enough. So documentation does matter. And how much and what to document is as much a judgment call as the decisions themselves.

Now, Gavin blogs eloquently and he's interesting. He provides rationale for his choices, defends his positions. And in blogging, he does this voluntarily because he obviously enjoys writing and he is good at it. Visual Architecting Process

Ok, so I propose that Gavin just reframes this documentation thing to "what decisions do I, as the architect (or we as the architecture team), think are crucial at this point (that's how we define architecture anyway!) and how do I best explain and defend these decisions? How do I connect the dots from my architecture decisions to the architecture drivers and to my experience?"

Now, I do believe that using the VAP Architecture Decision Model to organize decisions is a good idea, because an iterative process that focuses on resolving dominant uncertainties, risks and complexities/architectural challenges as its organizing principle can leave you looking for where you put your thoughts a few cycles back. But VAP is all about applying agile principles to system concept formulation and system design, but doing so with models as much as possible, and with proof-of-concept (use concept as well as architectural concept) code dives as needed.

But it still boils down to the architect's judgment. If you're working on a team of 3, the documentation needs are different than if you have a team of 30, or 300. If you're building a dog house or garden shed, you might draw some sketches, but do you hire an architect? Ok, what if the school your kids go to needs an extension, would you be happy if the same approach was taken? Context matters. Now we might have to nudge the architect to step up to the plate and use that judgment. I once asked an architecture team how they were going to make their architecture fly. In a blink, the tech lead had fashioned a flip-chart-sized paper airplane out of the conceptual architecture sketch. Not what I had in mind. We all laughed, but it was also a clear demonstration of what they were up against! We do need to make the early design decisions that will undergird system success. How do we make these decisions? How do we propagate these decisions? And how do we evolve these decisions?

We need to get to the point where we recognize that the system design is a product in of itselfthough it's value is only proven through the delivered working system. As demands and external forces change, the design must change to fit the changing context and changes in purpose. The design, and the code that manifests the design. This notion that the architecture gets out of date is just a feature of our lack of discipline around explicitly evolving the design. Within the scope of architectural elements, we give designer-developers considerable design freedom, and this bumps up against the architectural design. But when it does, the architect needs to oversee the change in architectural designor decide against a change in design if she or he judges that a change would interfere with the achievement of system objectives.

Many (most?) developers like to design as they code, using code as the medium in which they think about the design. This is partly a style thing. On my first programming job, I learned many things including i. don't read comics at work when you hit a roadblockyou can always find ways to answer your own questions and the place to start is to ask yourself new questions which you can find answers to. And ii. Even though I am a certifiable multi-tasker, I am hyper-productive when I separate design thinking from implementation thinking. When we design in conjunction with thinking through implementation details, we place a double load on our faculties. Which, though superior, of course, are still limited. We think too much about how and not enough about why and what else.

many hats If we're working in an agile team where "architect" is a hat every developer wears, then every developer-as-architect still needs to be diligent about changing the design and then changing the code. Yes, we will learn about changes we need to make in the design because we learn something from the evolving code. So? We still need to change the design. And this is why it is generally important to have an architect (and for big projects, a team of architects) responsible for the architecture. Otherwise we succumb to design debt, and its corollary, documentation debt:

Experience tells us that without having someone (or a team, for larger projects) responsible for the architecture, the architecture is no-one's priority, and it gives way to what is on the priority platefeatures that need to be released SOON! moi, 5/10/06

As this field matures, hopefully we will come to think of the design as a key deliverable to the business, for that is what it indeed is. The business just hasn't known to ask for it. But that is like buying a house and not getting the blueprintsif you recognized that piecemeal growth is desirable, then you'd want the blueprints!

I do want to return to Gavin's blog title: Does documenting your architecture make it high quality? Of course, documenting your architecture doesn't, in of itself, necessarily make it a good architecture, though it does get you to think about the system and the decisions you're documenting. Also, it does get the architecture out of your head and into a space where other people can react to it, test it against their experience, test it against stakeholder goals, and help you improve it. So, with an open and iterative process, documentation does help improve the architecture. And it does support the social process of getting buy-in and understanding, so that the architecture can be implemented, and evolved and matured.

In VAP, we expose the informal and evolving architecture to improvement and learning; we do so early and then often, applying the agile principle of getting stakeholder feedback to improve our understanding of the requirements and our design approach. To do so, we have to stay fluid, and it is perfectly ok to use hand-drawn sketches and hand-written notes documenting decisions, rationale, assumptions, constraints and other aspects of the context for the decisions. For a large-scale development, more formal ceremony may be needed to vest the architecture with an air of authority, and in such cases you may want to have a polished architecture document replete with artist-rendered images, models and views, and edited by a professional tech writer/editor. But you wouldn't want to start creating that formal document during early cycles when it is important to have a low cost of, and low barriers to, change. In any event, I believe that relying much more on informal processes is a key to effectivenessfor example, engaging in strategic conversations where you lead stakeholders through key aspects of the architecture, sketching and explaining as you go. Moreover, I don't believe there should be one architecture document. There's the specification, like the Constitution. And there's white papers, like the Federalist Papers, explaining and championing key aspects of the architecture.

(The Constitution metaphor is also covered in "What it Takes to be a Great Enterprise Architect," by Dana Bredemeyer and Ruth Malan, published by Cutter Consortium. Enterprise Architecture Executive Report, August 2004. Cutter is running a promotion, and you can download this issue free at http://www.cutter.com/offers/greatarchitect.html.)

08/09/08 Scaling and Architecture

Twitter architect gets hit by the blame-bus: Bug or architectural flaw? smoothspan blog, April 23, 2008
Some thoughts on Twitter's availability problems, Dare Obasanjo, May 22, 2008
System health monitoring misfires at Amazon: Fixing the root cause of Amazon's S3 outage, smoothspan blog, July 27, 2008
LinkedIn Architecture

08/09/08 Booch?

Grady Booch hasn't posted since June 12th... I assume he is just heads down working on the Architecture Handbook, busy Chief Scientisting at IBM, or enjoying some time off in Hawaii... if there was anything to worry about, we would have heard something wouldn't we? Well, I miss his posts!

08/10/08 Viable System Model

Stafford Beer's Viable System Model

08/10/08 tl;dr

Recognizing that my (uncut) journal suffers from tl;dr bounce-offs, I decided last month to create a trimmed down version for general consumption. I wouldn't tar everyone with the short attention span brush, by any means (though some exceptions apply). My hope is that as the few who do get drawn in find value, they'll enthuse and generate interest, and with someone else vouching for the great writing, wit, insight, and so forth, more people will get past their spontaneous tl;dr knee-jerk reaction that we have developed to save us from serious time pits on the i-way. Um, it is great writing, wit, insight, and so forth, isn't it?

08/11/08 Shocked, Appalled and Dismayed!

I am reeling from reading the following in a Training Services Agreement:

Licenses to Supplier Training Materials.

(a) With respect to any Supplier Training Materials delivered to XX as part of the Services but not incorporated into Custom Training Materials (as defined in Section 10.3), Supplier hereby grants to XX a non-exclusive, royalty-free, worldwide, perpetual license to use, reproduce and distribute such Supplier Training Materials for the purpose of training employees, agents and subcontractors of XX and XX Entities.

(b) XX agrees that the following limitations shall apply to its use of all Supplier Training Materials which are clearly marked with Suppliers (or third partys, if applicable) copyright attributions on delivery to XX:

(i) XX agrees that it will not on its own, or through third parties, reproduce or distribute such Supplier Training Materials as part of any formal training course except for such formal training as provided by Supplier.

(ii) XX agrees that it will not on its own, or through third parties, modify, adapt, or create a derivative work or cause a change in the ownership or license granted to the underlying Supplier Training Materials except for those express rights set forth in this Section 10.2.

(iii) XX agrees that it will not on its own, or through third parties, remove Suppliers copyright attribution.

(iv) Except as limited above, XX shall have the same rights under the copyright law to make copies of limited minor portions of Supplier Training Materials as if XX had purchased a copy of the materials.

Section (a) smacks of corporate imperialism! On the basis of buying one class, all rights to it are granted in (a). OK, then they are restricted in section (b). But if the client thinks that the terms under section (b) are reasonable, why state section (a)? And can't we just let copyright law take care of this?

I "detest, loathe, abhor, execrate, abominate, anathematize, disapprove of, am appalled, disgusted, fed up, and disabused by, have disfavor and disaffinity for, shudder at the sight of, and just generally Don't Like" (borrowing from Booch's erudite Valentine's Day email rant) CONTRACTS!

Needless to say, I'm not signing this one as is. Which means contract email. I "detest, loathe, abhor, execrate, abominate, anathematize, disapprove of, am appalled, disgusted, fed up, and disabused by, have disfavor and disaffinity for, shudder at the sight of, and just generally Don't Like" contract email!

Frankly, I think some of the stuff that goes into these standard vendor contracts is unethical!

8/11/08 Architecture and the Holy Grail

Code is not the Grail, value is the Grail. As soon as we frame it that way, we permit ourselves to do what matters. Code, absolutely. But not exclusively.

I wrote this back in February, but didn't realize the delicious literary serendipities until now:

We can't birth or evolve software solutions without writing (lots of) code and we get so focused on code as the holy grail, that we overlook the huge, huge waste in our industry because we forget that getting the right solution concept takes work; needs talent and time to incubate.

First, read this, and note the link between fertility and the grail, and then note my choice of imagerybirth, and incubate. I suppose it would be better if I had known what I was doing, but I'll take serendipity!

I wonder, did the Grails folk make this association with the great quest legends, leveraging the double entendre to subliminally message "this coding framework is the Grail"? I suppose not. But I guess they'll take the serendipity!

Isn't the software world just so fortunate to have me? Ok, that was a rhetorical question. I'm mindful of that Art and Fear lesson, and putting power in the hands of one who would like to "serve the world" by right-sizing my ego wouldn't be too forward-looking; not for me, at any rate. love my architect

8/12/08 Praise

I checked in on Rob Diagneau; so glad I did. I like Rob's style, and his code review template. Rob's commentary on comments predates much of the current debate, yet is pithy, salient, and balanced. The patterns posts (behind the data mapper, etc.) have whet my appetite for his promised book. And I like the way Rob deals with politics.

If I keep dripping praise, Rob will never be able to link here; so a quibble to hold against him. I suppose this is called "shooting myself in the foot," but Rob deserves the recognition and I can manage without my figurative foot.

Charlie Alfred's blog is moving house. I'll update my blogroll when he's done. I'm as guilty as anyone for lurking quietly, intimidated perhaps by Charlie's authority on the subjects he blogs. But sometimes we have to come out of the shadows and say "amen."

(Ok, have you read Maniac Magee? We loved it! "Amen!" With emphasis! Yes, yes, it's a children's storyfor the best of the adult in us. Principles in children are so pure. The adult in adultered is not misplaced.)

8/13/08 Enthusiasm Flows

School started back up in Bloomington today, and Sara was radiantly excited! Ryan didn't want to be early, because he's "in protest and that would send the wrong message." Under the bluster, I think he was eager to have his Summer freedom reigned in. I was sorry we "sold" Dana to a client in the Bay Area the first part of this week, so he didn't get to share the first morning excitement. But watching Sara's shining joy, as exuberant as it gets for a shy child, and watching the teacher's pleasure at this so transparent relish, impressed upon me again the positive cycle of enthusiasm.

Trying to bludgeon others with our ideas, raises resistance just as surely as bludgeoning with a stick. But unaffected enthusiasm, joy, touches others, sparks in them enthusiasm. (Generally speaking; our software world has its share of curmudgeons and others, burned out, too life-tired to spark.) Still, it helps to be passionate-enthusiastic about the outcome, but not passionate-obstinate about our conception of how to achieve it.

8/13/08 Lessons from the Olympics

Dana recounted that of Michael Phelps, a Russian competitor remarked:

"He's just a normal person... just... maybe from another planet."

I was telling Ryan last night (along the lines of motivating school) that every great person entered this world a baby, knowing nothing, without the strength even to lift its head. And it is by their effort that they became great. Every great person has worked at it. It doesn't come as a free ride. If we want to be great at something, we don't have to decide "I'm going to be great" but we do have to have goals, and we do have to work at achieving, even surpassing, them. Intellect, like body strength, takes work. You have to give some things up. The lunch table comment I overheard, rings in my mind"I need to read more. I've decided I'm going to clean my toilet less often, and watch less TV." It's a Muriel's Wedding moment, juxtaposing the tawdriness and glory of everyday life; here's a guy who's woken up to the possibility of himself.

And when the Olympics are over, he, and the rest of us, can watch less TV. I actually watched Michael Phelps swim for his first 2008 gold. Asked just after the race what was going through his mind when he won, he said "I was looking for my Mom, but I couldn't find her." In that unabashed moment, mothers hearts everywhere were stolen. Just think, all those mothers wishing him well. What a power to have behind one young man!

Being great takes work. And greatness is awarded. We award that distinction so much more readily, find it so much more compelling, when the honoree is uncluttered with vanity and self-serving artifice.

[Upon the blank slate we are born with, we collaborate with life to write our story. Some people fill the slate with stories of the struggles and the redemptions that are the path to greatness, and others just fill it with data.]

Yin and Yang 8/14/08 Thoughts on Reading and the Intellectual Journey

I read as much to be inspired as to be informed. Reading, for me, is inherently a collaboration with the provocative mind I'm engaging with. What I read is like Yin, and then what I see is also the Yang that completes the circle. This I say, mainly by way of explaining that my intent is not to be critical when I write or talk about my thoughts in reaction to other people's work. I intend only to reveal the complementarity, the Yang, I found when I was excited about the Yin they brought to my consciousness, helping to extend or re-organize my experience and insights in useful ways. Like the kittens, play fighting, in classic Taijitu form. As it happens, one male, the other female. Diversity of perspective helps us reach fuller understanding. This Yin and Yang thinking, for me, is not about opposites or differences, but about "and thinking." It is about "what else" am I inspired to think about, because I thought about this Yin. What, given diversity of perspective, completes the circle?

How does this relate to Paul Graham's disagreement framework? And how does such a question relate to Paul Graham's disagreement framework? It says there is something missingan agreement framework, perhaps? One where agreement has in its tail, a question.

8/14/08 Lessons from Madison

My favorite scout (yes, Dana) is at it again. He's been re-reading Madison's notes (Madison invented a short-hand to take verbatim notes during the Constitution Convention), and already on the second day they did something which I often shortcut. They established the rules of conduct for the meetings. And guess whatno laptops and no Blackberries! It's right there in the transcript! Well, the time-dated equivalent is there, at any rate. And here's another thing they set up: each person could talk at most twice on any subject of debate. Isn't that a great way to distribute the participation and make sure no one person dominates? It makes you pick the timing and content of your turn more carefully, etc.

"Every member, rising to speak, shall address the President; and whilst he shall be speaking, none shall pass between them, or hold discourse with another, or read a book, pamphlet or paper, printed or manuscript-and of two members rising [FN7] at the same time, the President shall name him who shall be first heard. A member shall not speak oftener than twice, without special leave, upon the same question; and not the second time, before every other, who had been silent, shall have been heard, if he choose to speak upon the subject."

The Debates in the Federal Convention of 1787 reported by James Madison : May 28; Yale Avalon project

I tend to treat people like adults who will behave well, and let them rise to my expectation. When they don't, I take it as a comment on how I'm doing, at my pace and how I'm directing attention and facilitating the flow of participation. I tend to associate creating the "rules of engagement" with dominance hierarchy territorial marking behavior, but I'm inspired to quell my anathema and give the Rules R in OARRS another shot.

I often find that when I'm participating in a meeting with architects, people talk to me, like they want my approval. I return the eye contact and signal that I'm with them, then draw their eyes to another person they need to meet and bring along. My approval is not what will get others on board. An external stamp approval helps, and that is part of why I'm there. But it is so important to be connected to the other stakeholders, to find what compels them, get their input, sense their reaction. So, I wouldn't want to take the Constitutional rules too far. Even if the CEO was in the room, I wouldn't want the CEO to be the sole person being addressed. This part of the dominance hierarchy thing I will continue to dispense with.

8/14/08 Journal Status

I've tried to be ruthless about the trimmed down version, and indeed, it has comparatively little Ruth in it. As an indicator, so far there are 516 words in the trimmed down version, and 5,680 in this undercover version. I'm prone to exaggeration, but it is accurate to say that this undercover version is more wordy!

But, judging by the hits on the undercover version, either people aren't very good at playing "Where's Waldo," or the trimming is being regarded a good thing. Overall, traffic on the site is down, but that's a general August phenomenon enhanced by the Olympics, so I won't take that as a silent voting of the feet just yet. But I will watch, because I sure wouldn't want the trimming to be treated as an insult; I don't equate tl;dr with short attention-span among people who have to guardedly conserve their attention in a crowded i-space of attention sinks. My trimming is a gesture of honor, not dishonor! That said, those who do seek their way behind the cover do naturally earn my still greater respect. Their quest is boldly advanced.

8/15/08 Do It Now!

I stumbled on Jeff Atwood's "Yes, but what have you DONE?" blog post from July 2007. It essentially makes the point that we've encountered in "Just do it" from Nike, "action not talk" from IBM, or "Do first things first, and second things not at all" from Peter Drucker, etc., but Jeff's post and the commentary emphasizes do it right now, and do it in code. We have, as a community, grokked that patterns have an essential triad: problem-context-solution. But process also has a key problem-context-solution triad. What is effective in one situation, doesn't necessarily translate into effectiveness in another. Like, if we have a complex system that requires expertise that is distributed in different heads, we need to create a shared understanding of what it is. And a bad experience in one context doesn't necessarily mean the "lesson" translates to other contexts as-is. (Profanity aside) I like the point Tracy Peterson makes in one of the comments:

"While I agree with the "DO IT ******* NOW" attitude in a broad sense, in the world of software development, particularly that for web applications the "DO IT" should refer to every step in the process, not just the ones we LIKE to do and if we didn't do our part right, we shouldn't force it out the door "RIGHT ******* NOW" or else we are only "*******" our users."

A built solution has a way of defining the problem; something being (generally perceived as) better than nothing. If we can do better at identifying strategic opportunity, and defining the technical strategy for achieving that opportunity, in "do it now" action-focused timeframes, we set those early code cycles up to be even more successful; the alternative being a random walk toward a self-defining, but ultimately compromised, solution. In highly competitive market ecosystems, the fittest survive. Trail and error and evolution are paramount forces. And Darwinian evolution may, under environmental pressure, be quicker than we had thought. But since we have that prefrontal cortex and can do better, shouldn't we? A discipline of iteration and stakeholder participation in problem definition and solution improvement is vital. We just need to ask what is the best vehicle, given where we are in the process, for learning and self-correcting toward a path of high value. Getting nothing done is so bad, that we forget that getting the wrong thing done is worse, because it precludes getting a right thing done a little bit later.

Strategic managers and senior architects have to balance survival in the near term with positioning for success through the long term. Project architects are closer to the now, making the project successful in the short term. Still, the project architect has to pay attention to structural robustness under evolutionary pressures, for no-one else has that as a priority in their charter. And the project architect is in a good position to use a slate of pragmatic techniques and skills to make the project a market shaping success in the short term, by getting the focus right, and empowering an impassioned team to move quickly towards a shared understanding of what value to deliver and how to do so.

We need to strive to simplify, but to reduce life to binaries is to sweep aside all the complexity that is the rich fertile mess on which innovation thrives. We are not trying to conquer complexity by hacking off it's limbs (a Monty Python skit comes to mind), but rather to harness it.

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

8/15/08 Time Management and Other Skills

Now, another serendipity. Dana was listening to Randy Pausch's Time Management talk in our shared office. It deals squarely with this tension between do it right and do it right now. Of course, when it comes to clearing my desk, I want to do it right, make sure I have a good plan of attack. :)

One thing that struck me, watching Randy, is how good he is at performing. He demonstrates leadership as performance art. Ok, he was a lecturer by profession, but most professors think that is the "underside of the banister" of their job, and they don't have to polish it up because the side that really matters is their research. Architects, too, often think that the real part of the job is making those tough decisions, picking the technology that will see the system through aggressive scaling, whatever, and that communicating effectively, convincing people and explaining and demonstrating solution approaches to them, is below the cut line on the to do list for today, and this week, month, quarter. But Randy, who betrays his tribal identity time and again with his opinions (the content and the number of them), has fun with it. He holds your attention as much but the sheer force of his enthusiasm as by his collection of stories and punchy bullets. He has props, he has jokes, and he has energy. Bounding, effervescent energy. Enthusiasm persuades. Just as soon as I get through my "important and due yesterday" to do list, I'll ... get to my "important and due today" list, and ... when I get caught up, I'll clear my desk. ;)

The real contribution to both my time management and yours, will be for me to stop journaling. Many, including Gerry Weinberg, recommend journaling. I think it does have huge value in shaping thinking, finding key messages, and so forth. I am more articulate when I talk, because I have tried to articulate my reasoning in writing. But my clients are asking for their bills! I have top architects in top companies, putting reminding me about my bills on their to do list! Wow! The great thing about the chief architects we work with, is that, to a man (the one woman chief architect among our clients defected to senior management) they are awesomely good-to-the-core people. Smart, yes. Experienced, yes. 360° talented, yes. And good hearted. So, chores! Ok, no more journaling!

Except for this hanging thought--you've no doubt heard about Randy Pausch's advice to hand-write thank you notes. Why? Because they provide a feedback loop. But he doesn't go into why that is important. Again, it is a tribal thing: Here is an action, take it. So, I give you Randy's own question "why?" The answer lies in Maslow's pyramid. Recognition (or the prospect thereof) is the base of motivation, necessary, though not sufficient, to achievement. You want recognition. Ok, pay it forward. Give recognition. I've met teachers, lecturers, managers, engineers, who think we've created a culture of compliment junkies. But empty compliments are not what I'm talking about. Have you noticed the power of recognition? If you give a forthright assessment of the value of someone's contribution, then you have gained twice: you are more aware of what you have learned or received (tangible or intangible), and you have deepened your channel of influence. People will want to be recognized by you, because you seek to understand their contribution and reward it with recognition. The desire to be recognized, I mean truly recognized for a meaningful contribution, for real work that was passionately invested in, is so strong, and so little fulfilled, that your approval will have surprising weight. I notice this from both sides, from my desire to be recognized by people I admire, and the desire of others to be recognized by me--which I take as implied recognition, because my opinion holds weight with them. You could use this insight in a Machiavellian way to manipulate people, you could shy away from it because you don't want them to "become dependent on you," or you could see it as a way you fit into the circle of life, nurturing and serving others who serve the bigger purpose you're jointly committed to! I'll just assume that, since you're reading here, you want to inspire and enable the people you interact with. Anyway, Randy's feedback loop on life point is vital, and you're a key player in the feedback loop for others in your network of influence, including your family and people you work with.

So, yes, I interpret Randy's thank you notes as notes of recognition for contribution. That's all very well, but Randy recommends a handwritten note. Again, I ask "why?" What does a handwritten note do? Yes, it messages extra effort, which is good. But I think the more important thing is that the recipient is more likely to treat it as a trophy of sorts, and post it up on their wall. The same person would get a warm fuzzy from an email, file it, and be done; it is physically uninteresting, looking like all other emails. The handwritten recognition is unique, interesting, personal and so gets pinned up, and then it is brought back to mind every time a visitor stops and notices it, so it goes on paying its reward long after the first warm fuzzy hit.

Randy Pausch had such great instincts and insights--wisdom, born of experience, bad and good. His family, friends and students lost the Randy they loved, but through their loss a world of us gained Randy. For years, his students got to benefit from his wisdom, but with a timebox on his life, that got bottled up in talks and a book. At least that.

I can't name names of architects I work with, but Grady Booch publicly leads by example in encouraging and recognizing key contributors in the software field. Much of what he has done in his blog is recognize others. He does this implicitly too, by championing the Computer Museum and gathering code exhibits for it, and in his selection of systems to be documented in his Handbook. He has done this so generously, and with such grace, he is leading the field in the example he sets, as well as in the work he's done and is doing. He genuinely, with integrity and insight, applauds others with such obvious delight and respect for their contribution, he sets a standard of sorts. Like, hey, praise from Grady ranks up there with a Jolt award. When we started Bredemeyer Consulting, we ran our first open enrollment workshop in Seattle, right in Rational's backyard. I can't even remember why we were so brash! But two architects from Rational attended, and we suspected they were scouting us out. We just thought "if a couple of great Rational architects like what we're doing, that says a lot." Several days after the workshop, Grady sent Dana a brief but spirit-elevating email, congratulating him on what he'd heard via the vine was a great workshop. That was a complete surprise, and it spoke to us deeply, for it is so unusual in our field for people to go that extra distance. People in our field are genuinely nice, but a note of appreciation takes energy away from all the other demands of their day--one has to notice what one is appreciating, and one has to take the trouble to write the email or note. That was 9 years ago and we still remember that email. It set in place a deeper respect for Grady that went beyond our respect for the work he has done, to respect for him as a person. He is a caring leader, who serves the field with passion and personal generosity.

8/15/08 Charlie's New Home on the i-way

No sooner said than done! Charlie Alfred is all moved in to his new digs at http://charliealfred.wordpress.com. Do stop by and leave a house-warming note. :)

8/16/08 Charlie is BACK

Charlie Alfred is not just unpacked, but he's cooking up new courses of insight! I have to say, he just floors me! Partly, I can't think of anything to add because I'm still laughing at his joke! Please, please take a look at his Conceptual Distance essay. Even if you read it when I recommended it a while back, he has added a new introduction and the great joke! I've seen Charlie write, and he is the Michael Phelps of writing about software architecture. Sure, he's done the behind the scenes work of thinking, investigating, and learning from the (often brutal) school of all the realities of an architect's job, but he puts together metaphor, story, humor, wisdom, insight and extremely useful conceptual frameworks with mind-boggling speed.

Of course, I immediately see the joke being recast as:

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.

Charlie characterized his Conceptual Distance post as a "mission of mercy" and I so identify with that characterization! As much as I try to spend my time on architectural mechanisms, I too often find myself drawn back to social aspects of socio-technical systems because that is where the pain (and joy) is. If we approach the problem right, we can solve it. Finding that right approach is hard, especially when our predilection is to jump to happy seclusion banging out code.

Now I have to go chase down Brian Sondergaard. He's another of my favorite architecture bloggers who's gone silent of late.

8/16/08 Olympics and Dreams

After I read Jeff Atwood's post and the comments with their "do it RIGHT NOW" and "dreamers are losers" message, it was fortuitous timing that Dana decided to listen to Randy Pausch's Time Management lecture! Randy, who had our tribe's proclivity to action in abundance, is very clear that dreams, vision, a sense of a destiny we forge, are essential to accomplishing big things. The Olympics is full of these stories, including Phelps saying that he knew that if things lined up right, he was capable of winning a record-breaking 7 gold medals (and possibly, if things don't go wrong, an 8th). He envisioned, and by hard work, action, and some luck, forged that destiny. He believed in himself, but what does this mean? It means he had a dream, a big dream, that he believed he could fulfill in part by aptitude and in part by hard work and focus. And, besides, he had a great manager.

Hearing Lopez Lomongs story is also inspiring:

"He knew nothing of the Olympics in 2000, when his friends at the refugee camp in Kenya talked him into running five miles and paying five shillings to watch Michael Johnson on a black-and-white TV set with a fuzzy screen."

A 15 year old boy from a refugee camp, running 5 miles in Africa, to watch an Olympic race on a black and white screen. The dreams that are wrought by the Olympics have an astonishing impact on the lives and the achievements of men and women you reach goals by working towards goals you've set around the globe. Great athletes, and the rest of us. For it reminds us all that we too, have our gifts and that with a dream, and hard work, we can do something that astonishes and inspires a world of people. Or something quiet, that astonishes and blesses a few, but of which we are proud. A dream without action is just a dream. Action without a dream is a dance with luck, and she is a fickle partner. Action focused by a dream, forges a destiny that will give our 80-year old future self peace.

I say all this by way of justifying letting Ryan stay up to 1am even on school nights watching the Olympics. Sara watches too, but being only 8, she falls asleep before it is that outrageously late. But this is the rich school of life, and there is probably no lesson at school during these two weeks that will be as important as the lesson about dreaming big and working hard, and being on that platform of success that is the reward. Besides, I like to listen to Ryan singing the National Anthem!

No, I couldn't just tape it! Canned dreams are about as zesty as canned peas!

8/19/08 Call for Papers

Call for Papers/Abstracts and Invited Sessions Proposals for The 2nd International Multi-Conference on Engineering and Technological Innovation (July 10th-13th, 2009 - Orlando, Florida, USA).
SEI Architecture Technology User Network (SATURN) Conference, Spring 2009

8/23/08 Way to Go Phelps!

With only one more day of this Olympics, only 9 countries have more gold medals than Phelps! And Australia, with a population of just over 20 million, it is in the top 5 on medal count!

8/29/08 Getting Past But

I. Finding Opportunity

- Innovation and value creation

-- Innovation and competition: Schumpeter's waves, Porter's competitive forces vice, Christensen's Dilemma; global competition, economic downturn; inside innovation

-- Innovation frontiers: technology, social networks and co-creation of value, business intelligence

- How to wonder

-- The idea team: what architects bring to value creation and opportunity identification

-- Creative foment: better than brainstorming

-- Think like a stork: system envisioning and desired state interviews

-- Taking a long view: roadmaps, projections and scenarios

-- Creating a compelling, shared vision

II. Making it Happen

- Strategy and Scope: where to look

-- Elaborating the opportunity

-- JEDUF: Just Enough Design Up Front

--- Dominant uncertainties, complexities, challenge and risk

--- Visual architecting and agile

- Socio-technical effectiveness

-- Technical effectiveness: making decisions and decision support--styles, patterns, visual modeling, tradeoffs

-- Social effectiveness: leadership, politics, consulting and coaching, communicating

-- Organizational effectiveness: roles, relationships and rewards; culture, capability and commitment

8/29/08 "I Used to Think. Now, I Just Read!"

Who said that? Larry Ellison, CEO, Oracle Corp. According to The Economist flier, that is. As for me: I used to think. Now, I just read--The Economist flier! Oh, that's so sad! Grin.

8/29/08 Chief Innovation Officer?

Should companies have a Chief Innovation Officer? Renee Hopkins Callahan
Innovate on Purpose blog, Jeffrey Phillips
Heads-Up on Organizational Innovation