A Trace in the Sand
Online Architecture Journal
by Ruth Malan

I also write at:

- Resources for Architects

- Architecture Action Guide

- Trace In the Sand Blog
 

HelpMatch:

- HelpMatch Wiki

- HelpMatch Google Group

 

- Other Interests

Trace in the Sand
Architecture Journal

- Journal Map

2011

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- Current

2010

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December

2009

- January

- February
- March

- April

- May

- June

- July

- August

- September

- October

- November
- December

2008
- January
- February
- March
- April

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

2007
-
January

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

- September
- October
- November

- December

2006
-
February
- March

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

- October
- November
- December

Topics

- Looking to the Value Chain

- Things People Look For

- The Road Home

- Recognition and Competition

- Why Getting Past But Is Important

- EA is Moving Out

- Architects and Analytical Thinking

- Visual Thinking

- This Journal's Turning Three

- To Redesign or Not to Redesign

- Putting Me Into It

- The Power of Context

- Mobility Buzz

- A HUGE Day

- Moral Leadership by Counterexample

- Moral Leadership by Example

- Help Turning the Corner

- New SOA-Erl Books

- Principles References

- Greatness is Earned

- What it Takes to be Great

- Happy Almost Anniversary

- Text, Context and Subtext

- Microsoft Layoffs

- Delight in Translation

- Engineering Excellence

- Trust and Integrity

- James Madison

- Doctrine and Principles

- Importance of Play

- Artifacts that Amplify

- Bushman, warriors...

- Caveat Lector

- Down to the Wire

- Upcoming Workshops

- Now I Get It!

 

 

Blogroll

Architecture

- Charlie Alfred

- Todd Biske

- Grady Booch

- Simon Brown

- Adrian Campbell

- Leo de Sousa

- Rob Daigneau

- Louis Dietvorst

- Kevin Francis

- Sam Gentile

- Adrian Grigoriu

- Simon Guest

- Todd Hoff

- Paul Homan

- James Hooper

- Alan Inglis

- Steve Jones

- Dave Linthicum

- Anna Liu

- Ruth Malan

- Nick Malik

- Chirag Mehta

- Gabriel Morgan

- Robert Morschel

- 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

- Wired's monkey_bites

 

Leadership Skills

- Presentation Zen

 

Um... and these
- Nick Carr

- Tom Peters

 

HelpMatch:

- HelpMatch Wiki

- HelpMatch Google Group










 

 

 

January 2009

1/8/09 Your Co-ordinates

This personal journal contains notes I take as I explore what it takes to be a great software or systems architect.

"Back issues" are linked on the sidebar.

In this journal, I muse, and ... perhaps ... by doing so, I become one. At least, I've labored for 10 years on the Bredemeyer site, and this journal is just weeks away from having 3 years worth of entries.    BaliHai, Kauai

1/8/09 Happy New Year!

We took a break over the Holidays, so my New Year greeting is somewhat belated. At any rate, I wish you a richly rewarding 2009 (see caveats).

We depleted my frequent flier miles bank to take the family to Kauai for the Holidays. It was a great place to learn how to conjure my Patronus to ward off the recession's dementors. Or, if we hadn't just finished the family reading of the 7th/last book in the Harry Potter series: it was a great place to reflect on where I've been and where I'm going; classic New Year stuff, in a setting of rain, sunshine, and rainbows. And the kinds of sunrises and sunsets you get when rain clouds are ever-present, though not omnipresent. Something like life, which is more vibrant with the texture of challenge and the meaning we make in our work, without which we would not have, from time to time, the rosy glow of accomplishment.

Photo right: View toward Bali Hai, Princeville, Kauai.
Below: Rainbow view from Anini Reef cottage.

Rainbows take rain and sun to make1/8/09 Looking to the Value Chain to Make It Through

While spending is under pervasive scrutiny, creative companies are looking at how to expand opportunity despite the recession. The Grove has taken a leaf out of Amazon's book, and has started an affiliates program. Of course, we're happy to refer people to Grove products without a 15% referral fee, and have long been doing so (for example, here). Still, companies that are value focused will be looking more and more to create value not just for their customers but for their partners in the value network. In tight times, relationships become even more essential and The Grove is moving to create a stronger synergistic network.    

This, by way of a client's email signature, fits the birth of the new year and turning one's sights to renewal and growth:

"We are all inventors, each sailing out on a voyage of discovery, guided each by a private chart, of which there is no duplicate. The world is all gates, all opportunities."

Ralph Waldo Emerson

 

1/10/09 Center for the Advancement of the Enterprise Architecture Profession

Mark Lane and Mark Goetsch have spearheaded the creation of the CAEAP or Center for the Advancement of the EA Profession. The number of people who have signed the Hippocratic Oath for the profession in just a little over a month indicates the interest in the EA profession, not to mention the great value we place on ethical behavior.  It is all very exciting!

1/10/09 The Things People Look For

On occasion (like... when I am really procrastinating about filing away the hard-to-categorize bits and pieces that hence end up finding a home on my desk), I look at what search phrases brought people to my site. It says a lot about what hard-to-categorize stuff has amassed in almost 3 years of this journal! For example, this search phrase "mr. magoo trap technical analysis" gives my journal 3rd place on a Google search, and pulls up a journal piece I'm happy to stumble upon—it's far back enough it's like someone else wrote it, and it makes an important point about the role of the architect in requirements! Another find—on the search term "architecture basics," my site comes up on the first page of Google results—well, it does today; Google search results are fickle. It brings up an entry that starts with Sara's definition of architecture that is really quite good. Why, I like that piece too! So, who's been writing in my journal??? 

And scanning down that page to the post on kayaking, I see that Dana's strategy rings a Potter bell: to conjure a Patronus to help one out of a moment of crisis, one must draw on a happy memory, a strong moment.

Mentioning Rowling's insights reminds me... This is a stark reminder of the strong biases women still have to deal with in the (late 20th and now) 21st century:

"Before publishing her first book, her publisher Bloomsbury feared that the target audience of young boys might be reluctant to buy books written by a female author. It requested that Rowling use two initials, rather than reveal her first name."

wikipedia (as of January 10, 2009)

150 or so years separated the pen name choices of George Elliot and J. K. Rowling, yet we still have men and boys who pre-judgeand dismisscontent by the gender of the author. It's so great that this doesn't happen in the world of software. Hmmm...  Don't get me wrong; I am very, very grateful for how much this is not a problem in software, even though it does hurt that it is a problem in software.    

1/10/09 The Road Home

Recently we watched The Road Home. It is artistic, poetic. Slow. Moving. Not for everyone; we liked it. The present is in black and white; the past in color. The seasons move with the story. Interesting in what is so different in a culture and time removed from our own, and in what is universal. The teacher leads the children in a chant:

"...set goals...

Write in your journal every day."

Tonight we watched The Diving Bell and the Butterfly. It is great! It's like The Last Lecture, in that it reminds us to celebrate and value our life, our loves, our gifts, what we are capable of-and this lesson is inspiringly, not depressingly, wrought.

Interestingly, Jean-Dominique Bauby and Randy Pausch both make the point, though they come at it differently, that humans need, even crave, approval. I tend to talk in terms of recognition, but Bauby and Pausch lend more weight to this counter to the position of Rosenberg and Derby.

1/11/09 Recognition and Competition

It struck me that at the end of his post praising Microsoft's Application Architecture Guide (blog entry on December 15, 2008), Grady Booch quoted Steve Balmer:

"We don't have a monopoly. We have market share. There's a difference."

This quote indicates that Booch is acknowledging that he is recognizing, and so bolstering, a competitor. That makes his recognition all the more generous, and statesman-likeas we would expect from a leader in our field. But the implicit reference here is not just to the IBM-Microsoft rivalry; it is to leadership in the architecture handbook/guidebook space, and the Microsoft team got there first. Of course, it is quite a different guidebook than Grady is working towards, but he is still setting a good example in pointing people to Microsoft's contribution.

And, in case you aren't tuned in to it just yet, I am a master of irony and self-directed satire. To wit, Microsoft beat us to it too! For I certainly see the Software Architecture Action Guide as an architect's handbook in the style of the AIA Handbook.

1/11/09 Architectural Style

Charlie Alfred's thoughtful article on architectural style helped clarify my thinking on the topic. Thank you Charlie.

1/13/09 Getting Past "But..." — for CIOs

Harwell Thrasher writes:

2. The business people won’t tell me their business strategy. How can I align with the business if I don’t know what their strategy is?

Answer: First of all, you probably know more about the business strategy than you think. Most senior IT people have a better view of the overall business than someone in any other business organization. That’s because IT interacts with so many different parts of the business, and it gets involved in the key processes of each organization.

So if the business people won’t tell you their strategy then put together a summary of what you think their strategy is and what the corresponding IT strategy should be. Then go back to the business executives and give them this speech:

I haven’t been able to get a clear idea of what our company’s business strategy is, so I’ve put together my own assumptions. Here they are (show them the key points of your version of the business strategy), and here’s what I think IT should do to support this business strategy.

What you’ll find is that most business executives who are hesitant to reveal what they consider “privileged” information are much more likely to correct your assumptions. So through their corrections you’ll end up getting the business strategy information you need.

Harwell Thrasher, MakingITclear Newsletter, January 2009

Who is Harwell addressing? CIO's! But the advice is pertinent to architects, too.

1/13/09 Why Getting Past "But..." is Important

You've read Getting to Yes and heard of Getting Past No, so why Getting Past "But"? Well, because "but..." is insidious, making it harder to get past than an outright "no." The person who says "yes, but..." is ostensibly aligning with you. Ostensibly agreeing but for this teensy caveat—this objection that is a showstopper! It can be resistance in a subtle guise, seeming passive yet inherently active—the kind of action that is actively rationalized non-action. Or it can be genuine goodwill—indicating a real desire to orient with you, and active intellectual, creative engagement. The trouble, though, is that "but" can become a barrier. We need the attitude that looks beyond "but." If we look only to "but," only to the objections, the reasons why not, we stop there. We need to look to what we want to accomplish, then figure out how to get there from here. We need to look beyond "but" to get past "but." Yes, Daniel is right—this is the stuff of "kindling the collective mind," engaging others in seeing how we would like things to be, then engaging their creativity in resolving how to get there.

I'm told "I agree with you, architects should play an active role in requirements, but reality in my organization is that the structure and process doesn't allow that." Yes, that reality is hard to change. And it will not, so long as the one person who could begin to make the change, the person who sees that the change is needed, doesn't start to lead the change! First, to see the need, then to help others see a better future, then to enroll them in creating that better future.

This by way of an architect's signature on an email I received this evening (a serendipity indeed):

"Reasonable people adapt themselves to the world.  Unreasonable people attempt to adapt the world to themselves.  All progress, therefore, depends on unreasonable people."

George Bernard Shaw

Yes, change can be hard, and it can take a long time to even get to the point where people recognize the need for change. It took Madison five years to get the parties to the table to create change. Hopefully it can take us less time to restructure the status quo in software development. Our Getting Past "But" paper is one resource you have to help shift perception and expectation. The Agile Movement also helps underscore the importance of multi-disciplinary teams. If your organization's approach to scale and complexity is to do just enough requirements and design upfront (for example, to spin off concurrent teams with enough context), you can still leverage the learning that the Agile Movement has embraced—multi-functional teams, iteration and stakeholder participation allow more concurrency to happen earlier, with better outcomes.

This from Jim "Cope" Coplien (I'm sorry I didn't see it sooner; it's an insightful post!):

"There is a close relationship between the structure of one's domain, the structure of one's interface, and the architecture of one's software." -- James Coplien, blog post, 12/4/2006

1/14/09 EA is Moving Out    

Brandon Satrom, assessing some of the accomplishments he contributed to at Compassion, wrote:

"the EA group will be moving out of IT and into the Global Strategy organization at Compassion. EA moving out of IT is a trend that Gartner is noting with increased frequency, and I am excited to think that the Compassion EA group will be among the first to align itself with the business WHILE maintaining a strong connection with IT"

Brandon Satrom, User Inexperience blog, 10/13/08      

Of course I like Brandon's blog by-line: "Architecture and User Experience...better together."

1/14/09 Business Architecture

1/14/09 Architects and Analytical Thinking

Einstein said:

"If I had 20 days to solve a problem, I would take 19 days to define it."

We might contrast this with:

"I have been impressed with the urgency of doing. Knowing is not enough; we must apply. Being willing is not enough; we must do." -- Leonardo da Vinci

Da Vinci was prodigiously productive (though it is said he was a procrastinator when it came to painting). What did he do? Designs, at least in good part.Hello World Proof of Concept Kludge

Designing is doing. Problem definition is action. In our toolkit, we have models and analysis on the one hand, and experimentation or trial-and-error learning, on the other. Iterating (placing value on learning from doing, from failing, back-tracking, advancing) is a problem-finding—problem-solving process. And we can apply this process to design, combining analysis and experiment.

"Lights On"  demonstrated supreme wisdom and good taste in linking to my blog, so I had to read his Architecture as Red Noise post. Grin. Though I wouldn't attribute the whole ball of mud to failed analysis on the part of the architect, I do agree that practicing analysis and system thinking tools is a good way to "sharpen the saw" and create better system designs.  Our new Lithuanian friend points us to The Thinkers Toolkit, and a Cognos review of The Thinkers Toolkit, in which Jones primary critique of our general problem solving approach is summarized as:

  • We come up with conclusions before we fully understand or define the problem.

  • Having missed our chance to understand the problem, we start our analysis with solutions we intuitively favor.

  • We confuse discussing a problem with analyzing it.

  • We focus on the substance of arguments rather than the process of the analysis.

Cognos, March 7, 2007

Tools like restating (I tend to use the term "reframe"—it's a "SWI-thing") the problem are important. And getting beyond the box of our assumptions. And I think of visualization as an aid to doing this. MindTools has a catalog of many tools (visual and analytical) for problem solving and decision making.

I've been planning some exercises for an upcoming Architecture Congress. The congresses are really neat, because there is time to practice skills between sessions (generally a month apart). One idea I've been toying with, leverages my experience with archman. No, I'm not going to have everyone plagiarize archman! As though they'd even want to! I picked up a tip from Hugh MacLeod, and adapted it, of course—instead of business cards, I carry a small sketchbook with me all the time, so when a visual idea strikes, I have something to put it down on. So, I want to give each architect a pocket sized sketchbook (to get them started), and ask them to pick a style of visualization, either of their own creating, or leveraging the example set by:

  • Jessica Hagy's Indexed blog and book

  • Christoph Niemann's New York Cheat Sheets
     

  • The Grove's Pocket Pics (practice with the Grove's visualizations of concepts, then create your own pictures for key ideas) and Milly Sonnenman's Beyond Words: A Guide to Drawing Out Ideas
     

  • Mind Maps (Buzan's The Mind Map Book )
     

  • The Power of the 2x2 Matrix (An option for the seriously inhibited when it comes to visual thinking/expression—at least we can spatially juxtapose our verbal thinking and push ourselves to think "outside the box.")

  • The Back of a Napkin
     

  • Others????
     

  • Oh yes, if anyone is interested in cartoons, I'd encourage them to read Scott McCloud's Making Comics. And I'd strongly encourage them to create cartoons for this exercise. It takes a lot of thought and insight to come up with a cartoon that is funny and intelligent. And (tasteful) humor generates goodwill and is memorable.

And create at least one diagram or cartoon, every day for at least a couple of weeks. Look, it's a great way to capture what is going on in a meeting, and it is one of those 'sharpening the saw" things we just need to do. Richard Feynman used to sketch people in meetings, using the time to practice his drawing skills. I think this application is a little more business-friendly while still fun and important! We need to get better at using visualizations to think and to communicate. A humble joke on meAn architect once told me "I think best in code; I just can't think in diagrams." We could gasp "and he's an architect??" but I totally empathize with this mathematician turned developer turned architect! Our education and our experience downplays visual expression and modeling, so we have to make a conscious effort to practice visualization (seeing with our mind's eye) and executing that visual on paper (or whiteboard... or a drawing tool). Milly Sonnenman makes the point that we already know how to draw (well enough), we just have to get over our own self-imposed hurdles. As you can see, I've done that to my own discredit. Grin. Well, I drew a Jessica Hagy-style chart to illustrate my own foibles. So, you see, when I'm humble, it may be that you're right, I'm an idiot. But it may be one of my singular points of talent and experience. I'd prefer that you assumed the latter. All evidence to the contrary, of course. Grin.

In making ideas visual, we see new relationships, have a tool for externalizing our thoughts, create a shared thought-space where other people can see what we mean and add to our thinking, etc. And then we can try alternatives—it's just a drawing! Architecture balances structure and function, qualities and servicesWe can experiment in models, to help us focus where we need to experiment in code.

Yes, I could suggest "create a UML model every day" for this two week assignment. But what I'm after is a stretch. A stretch. Going beyond the comfort zone, to see what one can do, and how it helps one think and communicate better. Ultimately, one wants a full "toolbox" of thinking and communicating tools, which definitely should include system modeling, probably UML (or SysML). But that is obvious. I also want to shed light on other analytical tools, many of them strongly visual, that we need to have more in our state of play. And other communication tools, tools that help us communicate better with the business side of the house, for example.

Anyway, having different people pick different styles of visualizing relationships and concepts, we'll get exposure to various styles and what people learned using them.

And, if you're wondering "why this?," well the architects have asked us, among other things, to focus on architectural thinking and communication. Both rely much on expression of the problem and its alternative solutions, and visual expression is a powerful ingredient of system thinking and analysis. So, I want to get a reasonably wide-ranging tablet of visual expressions into the experience set. (Of course they'll do other things—explore principles and patterns along the key design themes of their case study, for instance.)

So, that's the idea. Want to try it, and give me feedback so I can tune up my assignment?

PS. Did you scan the comments on this Hagy post? Some are hilarious!

PS^2. A comment on my "hello world"+duck tape cartoon image: It's amazing how "duck tape" has come to be synonymous with a quick-and-dirty hack, but at the same time, how powerful! Of course, there's the classic scene in Apollo 13, where duck tape saves the day. And there's what everyone else does with duck tape. This illustrates another point: the Duck folk have really done a good job of leveraging their user network to add ideas to the list of duck tape use models.

PS^3. The greatest thing about Jessica Hagy is her handwriting. I mean, can you distinguish it from mine? Wink. I guess I don't have to work on my handwriting after all!

PS^4. It's "a SWI-thing" refers to the internal HP software consulting group, the Software Initiative (SWI), that I was part of during my last couple of years at HP. SWI had a very strong culture, and with that, it's own language, and framing (and reframing) was a strong part of it. If you're into helping software organizations transform themselves, you get into a lot of "reframing." A quote attributed to Henry Ford, makes the power of framing (the terms in which you frame the problem) distinctly memorable:

 "Whether you think that you can, or that you can't, you are usually right." —Henry Ford

1/15/09 Visualization and Visual Thinking

Verbal thinking tends to be linear, while "picture thinking" allows for non-linear expression and thinking. So, you can see relationships and interactions, and perform thought experiments, for example, changing the relationships and interactions.

I read Sharky's post and watched these Kermit clips on YouTube (by way of Garr Reynold's Presentation Zen blog):

and I thought "Hey, visualizing software and visualizing jazz are not all that unlike!" Now, I ask you, where's the splot in UML? What would it mean? Where have you been? "Splot happens here," of course! And they didn't ask me to represent HP on the first version of UML! Outrageous!

1/15/09 Mark your calendar: This Journal Turns Three SOON!

Ok, for all of you who forget anniversaries and birthdays, this journal turns 3 on February 3! Last year, I reminded everyone, but still no-one took the opportunity to say "You are a model of grit and determination" ... or "I love your wry sense of humor—I don't understand it, but it helps me go to sleep feeling grateful ... that I'm not you!," or ... whatever! Grin.

Anyway, with three years of entries stacking up, I thought this would be a good opportunity to highlight some of my favorite bits and pieces:

Favorite line: We aren't mere windsocks responding to the direction of the wind; we make wind!

Yes, my trademark double entendre. In context:

One other flaw in much of the "we must respond to a changing world" thinking is that it neglects our impact on the world. We aren't mere windsocks responding to the direction of the wind; we make wind! We change the course of history, in small and big ways, with what we create. We change expectations about what is possible. We interact with destiny, don't just simply bow to it. Though, to be sure, we ignore these forces at our peril. But ignoring our role in shaping expectation, shaping the world into which our systems will fit, is just as one-sided as blindly expecting users to force-fit our product offering to their needs. The world of pragmatists is the world of balance, the world of tradeoffs. This is just as true for the process we adapt to fit our needs as it is to the products we generate thereby.

moi, August 2007

Favorite quote: "Listen, are you breathing just a little and calling it a life?" Mary Oliver

Book discovery that most excited me: The Wheel on the School [A $7 book that puts together the most important lessons of field-shapers like Kotter, Coplien and Harrison, and more, has to be an exciting find—even for those who don't have a child-like sense of wonder, it's good value for money! There, whether you're a creative awe-struck seeking sort or a down-the-line pragmatist, I've got you on that one.]

Love my architects!Please feel free to celebrate my ...tenacity ... by telling me why you stop by, or ... whatever.  I won't promise to put all your celebratory words on this page, because... well, frankly, I know you're busy... yeah, that's it. [It's not that I'm forestalling public embarrassment at the deathly silence in response to my unabashed fishing for compliments. Nah, that can't be it... Grin]

Anyway, siyabonga (or thank you, danke schön, merci, muchas gracias, etc.).

1/16/09 To Redesign or Not to Redesign, That is the Question

Arnon's post pointed me to "Uncle Bob's" post on The Big Redesign in the Sky. It's worth a read for it is witty and holds wisdom. But allow me to paraphrase:

Don't redesign because you won't be disciplined on the redesign and will just end up with a duplicate mess, slower. The only answer is to be disciplined about cleaning up the mess you have, today and every day.

We have no discipline, yet the answer is discipline...

Ok, so how much of your legacy code base is obsolete? Technologically, and functionally? How much is a structural disaster zone? Have your code bases diverged so much that the only recourse is to maintain n variant code trees? And you should never redesign?

"Extreme positions are valid in extreme cases. And only then." moi, 4/12/08 

(If you don't know me, the last part is irony. Satire in a nutshell, my dear Watson. Satire.)

Another kind of extreme position is "the whole shebang has to be redesigned at once." Sometimes this is true. Like, the hardware platform is being evolved to embrace technological innovations, and the change is so radical that the software platform for the product family has to roll too. Or development environment support on a new platform provides so much greater productivity that rolling the system is indicated (in the medical sense; grin). But the architect is a pragmatist. Pragmatically, the architect needs to weight the options. Redesign or refactor; partial or radical.

I live in the software world, so that is the world I know. I don't know if other people are so predominantly like this, but we sure do like binary logic!

Black and white, either-or options. And checklists!

And in both cases, I get uncomfortable. We need to strive for simplicity. And we need to leverage the knowledge and experience of others. And we need to think about the demands of our situation!

If you want some bold advice, it is this:

For systems that the competitive advantage of your business depends on

  • develop your system incrementally, actively simplifying, refactoring, cleaning up, redesigning as you go

  • obsolete your system, redesigning and rebuilding it from scratch every three to five years

Why? If you don't, a competitor will! But don't—please don't—just rebuild a cleaner version of your old system. That is where the whole rebuild trap lies. Build a new system—build the system a start-up would build to knock the socks off your legacy-bound system and trounce you in the market!

"The Stone Age didn't end because of a shortage of stones!" Al Gore, live broadcast on 7/17/08

Every build from scratch project has to look forward, not backward! If looking forward, you see that you need to bring the past with you, well and good. But chances are, where your customers are going they're not going to care nearly so much about your legacy as you would like to think! Yes, they'll have a point of resistance but the ever changing competitive context will push them past that.

I learned an important lesson from Bounty paper towels: when the rolls with closer perforations came out, I was frustrated at how hard it was to get a "full-sized" towel. But very quickly, I adapted to using just enough paper towel for my emergency. Now I even tear my half-size strips into quarter size strips, if I don't need the extra paper. The product led the consumer, but in a context of growing consciousness of the value of green. Bucky Fuller's technology gestation rate is important to understand, but has to be taken in the context of context! If your part of the world is moving at avalanche speed, expect the gestation rate to be swept along with it!

Remember though, bold advice is only that—bold advice. Advice to be taken advisedly! The source may count, but your judgment is why you have the big title—aRchitect! Reason about and rationalize your choices against value and challenge and risk, now and taking into account the future you are leading your organization and its products and services into.

Your legacy represents a huge investment, a wealth of intellectual property, and it is worth working hard to keep that vital and viable, investing in ongoing system health, structural integrity and value renewal. But it is also entirely sunk cost if it is going to be obsoleted in the marketplace, and it is better, though hard—hard to the point of most unlikely— for organizations to obsolete their own systems. Rechtin's Why Eagles Can't Swim is a great reference, as is Christensen's Innovator's Dilemma

From scratch "next gen" efforts are very risky, and highly prone to being cancelled before they have a chance to mature and prove themselves in the market. Splitting resources between sustaining the "legacy" -- or the current system under (d)evolution -- and the next gen system is hard for the organization to sustain, next gen system invariably cost more and take longer than anticipated and often doesn't fare well under scrutiny when belts have to be tightened... There is a lot to weigh. But the architect working with the management team has to do this on a case by case basis. No easy glib "don't redesign" or "redesign every 3 to 5 years" is going to be universally "right." ARchitect; identify opportunities, experiment enough to know which are most promising, and show incremental value, looking to leverage existing investments but being watchful lest legacy investments are just plain encumbrance given where the market is headed.

As for checklists, I touched on the topic of checklists here, but I had a bad link (and no-one pointed that out to me; I highly recommended it, yet no-one tried to follow it??? Grin). Anyhoo, I fixed the link (and added one), and it's well worth a hop—great stories/analogies.

Structural Analysis Tools:

Joel on Software also has a (characteristically) polar take in "Things You Should Never Do." He makes (characteristically) good points, colorfully. But I try to remember "never say never" (grin). Again, aRchitect--apply Reason and good judgment! The picture is generally complex, with lots of factors to weigh--whether we are deciding what to do going forward, or trying to interpret the lessons history teaches. For example, according to this wikipedia entry: IE 5.0 was released in March 1999 and IE 6.0 was released in October 2001 -- or 2.5 years between releases. Netscape 4.0 was released in June 1997 and Netscape 6.0 in November 2000. So simply pointing to 3 years doesn't provide the insight we need. We need to know if IE 5.0 leapfrogged Netscape 4.0 sufficiently to garner the market and buy Microsoft the leeway to spend 2.5 years on its next release... or was it something else, like Microsoft's market presence?)    

1/16/09 Putting Me Into It

Well, at the kids urging, I got to see Marley and Me tonight. I had more fun with it than I anticipated. I just loved John Grogan's boss! Imagine—supporting a writer who puts himself into his writing, is funny, all that... I'm laughing my head off. No, really, I am. Ah, the power of context.

They say that the definition of insanity is doing the same thing over and over and expecting a different result. But isn't the definition of hope getting the same result over and over and still expecting something else? At any rate, my command and control piece comes to mind. Again. The kids still don't close the door when I ask them to. And yet I still ask them to. After all this time. And I still hope that my values will somehow stick when my behests do not... Insanity or hope? Or, is that "willing suspension of disbelief"? You know, it's how we get through life! And it's what we ask of our developers! And managers.

1/18/09 Speaking of Favorites!

I just read Charlie Alfred's latest post, The Seven Deadly Sins of Product Development, and I have to say, of all Charlie's essays and posts to date (and they are all excellent and absolutely on-point for architects), this is my favorite! Well done Charlie! I most heartily recommend it!

1/18/09 Architect Jobs

Well, there are openings for architects in California, at least. Southern California Edison is hiring 3 architects and Intuit is moving into the cloud apparently, and with it, also creating 3 new architect positions:

Software Architect Req 67357—Mt. View, CA

  • (very Sr. Architects)
  • BI/CRM Cloud applications, Oracle, Hibernate, J2EE

Cloud/Virtualization Architects—Mt. View, CA Network Req 65738 & Edge Computing Req 66216 —Mt. View, CA

  • Cloud/Distributed/Grid computing knowledge, Virtualization exp., design exp.

1/19/09 The Power of Context

As I have come to see it, one of the most important things the architect does is set context for the development team. In more complex organizational situations, like large development projects or distributed teams, it is important to do this explicitly for organic, ad hoc communication, by itself, is too hit-or-miss for something this vital to project health and success.

Context—business and product context, and technical context—is what enables the team to be empowered, because context—appropriately and adequately set context—provides the means for alignment not just on surface objectives and priorities, but on a deeper understanding of intent and meaning.

So what do I mean by context? On the business side, I mean the strategic vision (vision, strategic goals and roadmap), and an understanding of what makes that vision make sense for the organization or product—a rich picture of the competitive landscape and value stream context. Now, this is not typically the bailiwick of the technical person. But we do need to convey this context, and motivate why we are doing so. To empower decision making, we need to share enough of the context so that decisions line up with the differentiating value propositions of the system, product or service.  Yes, the architecture translates business/product strategy into technical strategy. Still, so many decisions are made during development, that sharing the business/product context directly, as well as through the architecture, helps achieve alignment through the myriad diverse decisions that are made throughout the project.

On the technical side, I mean the architecture creates technical context. Architecture strategy, and the conceptual, logical and execution (physical) architecture decision set and the considerations that make these decisions make sense, create the technical context for design and development decisions. All context does not need to be created at once, nor can it be. But as this context is understood and assimilated, created even, it needs to be shared.

Agilists emphasize talking about the system over documenting it. Talking about the system is for those who are part of the conversation at that point in time, and it has strong advantages in participation and so energy, as well as being able to dynamically shift the conversation to address uncertainties, ambiguities, questions, and whatnot.

Writing about the system is for those who will read what is written, now and into the future. You can guide and direct the flow of attention, and the reader can backtrack to go back over a point that needs more of their attention to grok, for example. And the writer can go back and fill in, clarify, amend.

Recorded conversations, both the structured presentations and unstructured reviews, provide a mechanism to pass some of the benefit of the communication into the future. This is important to do but can become an unstructured time-consuming mass. Creating a recommended selection of video clips and readings is a good way to bring new team members on board, supplementing live meetings and reviews (for these shouldn't be waived away just because there is more of a bit trail than just code).

So it is still important to write about the system. It is often easier, for those whose style meshes well with reading, to navigate a document (or set of documents, tailored to addressing scoped concerns). And the act of writing also helps the architect get more clear about what she or he wants to convey. It helps to prioritize, to think things through more deeply, to explain, and... more that I'd write but all the project demands of today press upon me.   Wry grin (it's what we all say... we'd write more, but project demands press upon us...)

1/19/09 Mobility Buzz

Cutter wants your help putting it's finger on the pulse of the buzz around "Mobile EA":

"Mobility offers advantages for the business, thanks primarily to two characteristics: location independence and personalization. Cutter Consortium’s latest survey investigates mobility trends in organizations, including changes to the business model, adoption of mobile technology, and the social impacts of mobility. I hope you'll let us know your opinions by participating in our research.

Receive your immediate, complimentary copy of the Cutter Consortium article Mobile Enterprise Architecture: Model and Application, when you complete our survey on Opportunities and Challenges around Mobile Technologies, at http://www.keysurvey.com/survey/236483/e7f7/ 

About Mobile Enterprise Architecture: Model and Application

A comprehensive Mobile Enterprise Architecture (MEA) treats mobility not as an add-on to the existing business processes but as an integral part of the enterprise architecture. The MEA enables an enterprise to achieve the advantages from mobility while reducing the risks associated with its implementation. You will learn what constitutes an MEA and the value of creating such an MEA for an organization. You will investigate the advantages and limitations of an MEA, creating and using a mobile application development platform, the MEA roadmap for transition, and the mobile service-oriented architecture."

Email from Cutter Consortium, 1/18/09

1/20/09 A HUGE Day!

Peter K. from The Netherlands wrote this on his Bredemeyer Resources for Architects mailing list sign-up:

"Your site is a bright one and an eye opener for me as well."

Can words really make a difference, and why do we expect so much from Obama today?

Kennedy said:

"we choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too."

We choose to go to the moon, John F. Kennedy, wikisource

Gus Grissom heard these words, and was inspired and determined to do it. He never made it to the moon, but his role in the space program was forceful. He was the driving "customer" who the user experience was so shaped around, the spacecraft was too small for other astronauts!

Words do make a difference! A leader's rhetoric can inspire a nation, a world even. And these words of inspiration align, motivate and empower action. This is a day to go down in history, and much, perhaps too much, is expected from this speech and the man who will make it. But he is a leader, and leaders are great because of the greatness, the great contributions, of all the people they inspire and align.

1/20/09 Moral Leadership Demonstrated by... Counterexample!

The board at our Montessori school voted to not show the inauguration (swearing in and speech) today, because they didn't want the kids being on either side of a "my guy won" thing. One of the parents, a political science professor at IU, responded: "That's the text. But what's the context?" The context is that this is a historic moment from so many perspectives. We're in a recession and the general global mood is very depressed. Everyone expects Obama to speak to this crisis, and if that were the only thing, it would be big enough because a financial crisis of this magnitude impacts everybody! And this is a bigger moment even than that. It is a momentous moment in the US civil rights movement. Moreover, this is a global moment—a moment when the child of a world union, a union of an African and an American—is sworn into not just the top position in the US but also a position of global leadership. Yes, this is a big moment. It is bigger than America, and children will be watching this moment LIVE around the world. This is a big moment in our time, in our country, in the world, and in all of history.

Well, back to my various and varied ongoing projects. Deadlines loom.

1/20/09 Moral Leadership Demonstrated—by Example!

Wow! An inspiring speech delivered to this nation, and the world. We joined friends and watched the Inauguration in a rather festive atmosphere, so I went back and reread the speech, and it gets still better with concentration. For it is a speech that is full of wisdom and hope, and a call to imagine and to do.

"Now, there are some who question the scale of our ambitions — who suggest that our system cannot tolerate too many big plans. Their memories are short. For they have forgotten what this country has already done; what free men and women can achieve when imagination is joined to common purpose, and necessity to courage.

... The time has come to reaffirm our enduring spirit; to choose our better history; to carry forward that precious gift, that noble idea, passed on from generation to generation: the God-given promise that all are equal, all are free, and all deserve a chance to pursue their full measure of happiness."

Barack Obama, 1/20/09The storm is upon us, yet we glimpse the rainbow of hope--and the child who spells our future

Leading in to the Inauguration, a commentator said "Today, history will be changed." I raised an eyebrow, and a friend remarked "You know, as it always is. Re-interpreted. Rewritten. Changed." But today, history was made, and that history does not need any changing!

"The time has come... to set aside childish things." But not childlike things. Not wonder. Not hope. Not imagination. Not simplicity. Not virtue. Not a propensity to action. Not a belief in our own capacity to do, and make, build, create what we imagine. Not happiness.

President Obama—Amen!

1/20/09 The Grove Wants to Help Turn the Corner

"Our nation is seeing a phenomenal course change this week. As we all conjure hope, plan for our dreams and imagine our future at the beginning of a new era, The Grove is offering a special 30% savings on some of our most popular strategic visioning products to help you make plans for your own change."

Isn't that a great way to move forward? Not getting stuck in the morass of today's woes, but thinking instead about where we want to be, and how to get there. What are our customers' hopes and dreams? And the hopes of dreams of everyone in the value network, inside our organization and outside? How do we put together value, so that despite the economy, we create the kind of compelling value that gets us where we want to go.

But, times are tough, and since you probably won't find the 30% off coupon code at something like CouponCabin or RetailMeNot, you could email Noel underbar Snow at Grove. (No, we haven't joined The Grove affiliates program; I like being a free agent.)

1/20/09 New SOA-Erl Books and Community Site

Earlier books by Thomas Erl that have given rise, in my assessment, to a SOA-ERL architectural style:

And more from Erl:

1/20/09 Pulling Together Principles References

I'm pulling together references on principles. I've made stabs at that before, so those first:

Examples of Principles from Outside of Software and Enterprise Architecture

  • Definition of principle on wikipedia

  • principles definition from BusinessDictionary.com:
    "Fundamental norms, rules, or values that represent what is desirable and positive for a person, group, organization, or community, and help it in determining the rightfulness or wrongfulness of its actions. Principles are more basic than policy and objectives, and are meant to govern both."

Principles governing (professional) conduct:

Examples in Software

Examples in Enterprise Architecture

Guidance on Creating EA Principles

Your Help

If there is a paper or set of example principles that you like, please share it with me, and I'll share it with the community (with credit to you, if you allow me to mention your name).

[1/5/09: ARMA code of ethics and Kennedy's Consumer Bill of Rights.]

1/21/09 Greatness is Earned

Grady Booch's selection (1/20/09) from Obama's speech reminded me of his witty quip (post on 9/8/08) about IBM, Microsoft and Google. Anyway, Grady's quote included these important words about the greatness of a nation:

"In reaffirming the greatness of our nation, we understand that greatness is never a given. It must be earned." — Barack Obama, 1/20/09

Greatness must be earned. And greatness is a distinction that is awarded, not self-proclaimed (though dictators may try). This reminded me of a piece I wrote in response to Michael Phelps, about the greatness of a person:

"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." moi, 8/13/08

Which is not to say that all great men and women are humble. Take Steve Jobs, for example (I don't know him personally, but the public projection is not of a humble man). But humility is a supreme quality in a leader, for it allows for, even relies on, the role of others in making headway toward great accomplishment.

"It is by grace and by the efforts of those before me and beside me that I am where I am and can do what I do, and for that I am humbled." -- Grady Booch, blog post on 1/20/09

Greatness interests me greatly, of course, for the mission I've wrapped my identity around, is to help architects be great.

1/21/09 What it Takes to be Great

Being that my mission is to help architects be great, I can only strive endlessly to be great by helping you be so. Your success is imperative to mine. But it is not sufficient because, well, you bring something to this too (so, alas, I don't get to rack up your every success on my scorecard)! Moreover, to be great, you depend on all those who work with you to make your system great, and I depend on you. So, I'm rather far back on the big food chain of greatness. :-) So far back, that it takes only the biggest of people to notice and say that I or we (Bredemeyer Consulting) played a role, if only to fuel the torch of the pursuit of greatness.

Looking for wording around architects being great, I read over the workshop FAQ on our upcoming What it takes to be Great: The Role of the Architect Workshop and this piece, in particular, struck me:

What is the value of this class? A successful architecture forms the platform for strategic advantage. By contrast, the lack of architecture bonds the organization inescapably to its past. Our legacy is a tortuously tangled slew of haphazard systems born of a time of amazing wizardry but little system discipline. These legacy systems are expensive and hard to change, but replacing them threatens the very "life" of the organization. To break the chains of our corporate legacy and build systems that fit the environment, and adapt with the environment as it changes, we need superbly talented architects. Just architecting adaptive systems requires a lot of our architects, but our architects have, at the same time, to lead the organization into a new era of system thinking and system discipline and this requires an even greater set of talents and repertoire of skills.

We understand the multifaceted nature of the challenge, and this workshop is designed to help architects see where they have strengths and how to build on them, and where they have gaps and how to address them.

Literally thousands of very talented and experienced architects and tech leads have taken our classes. Even the most experienced architects consistently identify important insights and lessons that the class has brought to them. We use some lecture to cover concepts and conceptual models to help organize and expand knowledge and insight, but our emphasis is on stories shared by peer architects and the instructor to expose hard-won lessons, as well as large group, team and individual exercises to learn techniques and practice skills.

Role of the Architect Workshop FAQ, Bredemeyer Consulting

Goodness, why isn't that class full already?? Wry grin.

1/22/09 Happy Almost Anniversary

I'm going to share some of Charlie's response to my unabashed solicitation for compliments on the almost-occasion of the 3rd anniversary of this journal.

"So why do I visit? There are several reasons:

  • Your writing style is informative and entertaining at the same time. This is a terrific quality, and is the primary reason why I prefer the undercover version. If you are going to eat an ice cream cone, there’s little point in tossing the ice cream and just eating the cone.

  • You consistently champion the most important topic in architecture – figuring out what people really want and need...

  • You do a really nice job of keeping me posted on what’s going on in the industry...

  • ...

  • I know how much you like to see page hits and want to do my part.

So, keep up the good work!"

I feel the same way about ice cream. In fact, keep the cone—I'll take my calories with a full helping of cholesterol thank you.

As for page hits, thanks to each of you for doing your part! In the general absence of direct feedback, I take your visits as an implied compliment—especially the increase in the return rate of visitors. Actually, this last is a troubling phenomenon, because it puts pressure on me to deliver ... ice cream.

1/22/09 Text, Context and Subtext

I'm preparing for a meeting with some architects, ostensibly to go over the text of a couple of their documents. But what I need from them, to make any impact, is the context: objectives and priorities and a broader perspective that informs the objectives and priorities. And the subtext. And this is where things get really interesting, for it is about trying to get the elephant in the room talked about in a way that doesn't raise resistance and barriers, and lets us make everything discussable without driving wedges. (Yep, Randy Pausch left his mark on my cognitive frameworks in distinctive ways, and that "elephant in the room" notion is powerful.)

There are those (and not just "IBM") who dismiss talk, but dialog is essential in understanding the opportunities and resolving the challenges inherent in architecture. Enterprise, product family and system architecture by nature cuts across charters, and the turf battles are often not overt nor even discussable. Everyone is working for the same company; to suggest an impedance mismatch between the parts is tantamount to suggesting disloyalty. So the needs, concerns, passions, values of all the vested parties need to be heard, understood, integrated into the decision space.

1/22/09 Microsoft Layoffs

Microsoft has caused a stir with 1,400 laid off today and news that 3,600 more are set to lose their jobs "over the next 18 months."  For those impacted, it's a shock. What came as a surprise to me, was the amount of anti-Microsoft venom that was being unleashed in the comments on mini-Microsoft's blog. In the varied encounters I've had with Microsoft people, I've been very impressed by how smart and gracious and multi-dimensional they are. Energetic, interesting, caring and responsive people. Ten years ago (when I didn't know very many Microsoft people), I might have succumbed to the caricature of a smart guy with the arrogance of a top league super-star, but I can most emphatically say those are not the Microsoft people in my relationship/experience base! Smart, yes—superbly. Shallow and arrogant, no. So I feel bad for the uncertainty the news brings, but worse for some of the actual reaction! Microsoft has been playing an important role raising the standing of our profession and helping to extend our field's knowledge-base and tool-sets. They deserve applause and I hope it will be heard above the din of the bad news.   

Closer to home: I was wondering, seeing stores and businesses in Bloomington closing every week, how many people in Bloomington alone have lost their jobs.

The storm is upon us. And yet we have clients all over working on really exciting projects, and I think the bigger news in the Microsoft announcement may be that those who can are putting a cautious foot on the spending brake because aggressive cuts will put more spin in the downward economic spiral.

1/23/09 Delight: In Translation

I know, I beat the "delight" drum ad nauseam for while back in 2006/7 (12/19/06, 1/24/07 and 1/25/07, 2/1/07, 5/15/07, 11/30/07 and even 3/2/08). At TED, Yves Behar said:

"Advertising is the price companies pay for un-original designs."

And advertising is the price we pay for products that don't sell themselves, don't create advocates in word-of-mouth customer-to-customer promotion. In Opening Up the Innovation Engine I made the following point:

"We can't expect marketing to create brand miracles no matter what products we create, and we can't expect our sales force to create customer relationships and sell our products even if they generate bad feelings by delivering a shoddy customer experience!"

-- mere moi, 6/17/06

There's an important relationship between strong designs, quality products and marketing, and I'm excited about a paper I read today. Now, at first blush it is not on point for software architects: "Winning Back American Consumers" was first published in Chinese and directed at marketing and strategists (by UC Berkeley Haas School of Business professor Lynn Upshaw).

But consider this, as an industry, unless we focus on quality that delights in software, we will deserve the same tenor of lecture from Upshaw as China was getting! Our branding as an industry is tarnished by systems that fail in news-worthy ways, but more insidiously every day by user experience that frustrates. Does that matter? Well, it impacts our ability to attract design talent, for one thing. While software development is seen as a geeky pre-occupation with technology (for its own sake), rather than an exciting design domain focused on user experience that is meaningful and delights, we're behind the eight ball on attracting from other talent pools, especially talented women, into the industry.

So, anyway, I think the paper holds a lesson to be taken to heart as an architect, as a business, and as an industry. Ok, some translation is required (from messages directed at China) to software and architecture, but the essay makes important points about the relationship between quality/product integrity and brand integrity.

Though Lynn Upshaw's focus is marketing, he is quite clear that brand is about design and quality, not just marketing:

"Integrity for brands is very similar to personal integrity. It is about standing for something real and authentic in the eyes of customers and prospects, no matter what might happen within the marketplace. Such integrity can become truly disruptive to the competition, especially if it is an industry that may have had in the past one or more competitors that did not always take the high road."

Upshaw writes:

"Create Systemic Integrity – ... The stakes are so high in this relationship between China and the United States that there will always be the temptation to reduce costs that can threaten product safety, to soften quality controls, and to produce and sell goods and services in questionable ways.

For China – or any country – to address this temptation for the indefinite future, there must be an integrated set of values and actions that are adopted at the manufacturer/marketer level if superior quality is to become the norm. It is in this last arena that the problems are the most difficult to solve, and yet provide multiple benefits for both buyer and seller, once they have been solved."

If we reframe this in terms of technical/design debt, we find ourselves slap in the middle of the systemic integrity point. The temptation to be fast, increasingly under the nom de guerre of agile, can soften quality controls and threaten product usability, reliability, safety and lifecycle cost. 

Upshaw recommends:

"Assess quality against the ideal, not the adequate – Frequently, there is a temptation to do what is necessary, without considering the normative. Companies with strong product integrity compare their performance to the ideal, not to the common denominator."

Well, I've been ordered back to "my life"... Dana has a bit of a travel hiatus, and is reading The Hobbit at bedtime.

1/24/09 Integrity and Engineering Excellence

Now, let me hasten to add, that I don't harp on about "delight" and "product integrity" only because it is important from a standpoint of value to the customer:

This "circle of excellence" notion is exciting, because it brings to the foreground the fact that for customers, and for development engineers, excellence is compelling.

moi, 11/30/07

I think it is essential to our organizational "health," to internal organizational integrity, that we create soundly engineered products that delight customers. Engineers want to be on the winning team, to be proud of the products they engineer—proud of the market success and proud of the product's integrity. Nothing has impacted me more than working on a project where quality was slip-slip-slipping under the schedule gun of overly aggressive weekly integration targets. The morale level was disturbing, and it wasn't the pressure per se. People liked the camaraderie of working so hard together to make the targets, but the undercurrent of concern about quality, about technical debt, was eating away at that camaraderie like a cancer.

Now, before you think that I let the lesson of that experience color my attitude towards agile, let me hasten to say that I think there are two agile tides out there. One, where "agile" is the facade behind which projects hide many of the ills that plague software development; erosion of structural integrity or design debt being one. Quality issues and technical debt (a front for quality issues) are bad for software and bad for the "agile brand." True agile is practiced with faithful adherence to the principles and values of agile per the Manifesto and subsequent evolution of the Agile philosophy. The same underlying values, principles and central tenets have shaped the Visual Architecting Process, with the caveat that models need to be viewed as bona fide vehicles for getting stakeholder participation during early (and short) iteration cycles, and with the caveat that users/customers are not the only stakeholders we need to take into account:

Remember, as architects and software developers we have TWO (classes of) voices to listen to: the voice of the customer and the voice of the business. The business cares about our attention to the voice of the customer, because that is how we compete in the near-term. But the voice of the business is also about the long-term viability of our business and the systems and products that support it.

moi, 3/16/08

Engineering excellence is about creating products that delight, because the user experience is superb and the product integrity does nothing to erode that experience. And excellence is a long term value proposition, for it lowers life cycle cost to the customer and to the business, and lowers sales and marketing costs in an increasingly savvy, increasingly skeptical, increasingly connected customer space.

Engineering excellence is good for engineers, and it is good for business results. The Hewlett-Packard that Bill and Dave created, proved this.

Of course, I grant that perfection is hard in software:

So, it is not just that humans aren't "fully debugged." It is the sometimes predictable, often not, myriad interactions that make it so hard for us to get systems "perfect." The beliefs and expectations of the user, and the beliefs and expectations of the software designers and developers, are complex and not necessarily known or knowable in advance of some peculiar mix of circumstance. Then you get situations like the F22 crash described in accident report S/N 00-4014.

moi, 3/23/07

But the pursuit of excellence is integral to our pursuit of happiness.

1/25/09: Here's a great story about technical (a.k.a. design) debt. Life is full of compromises. But if we let the compromised system hit the market (ship the prototype), we create an integrity deficit. And we don't want to be associated with a phrase that is associated with... ok, moving on...

1/24/09 Trust and Integrity

I grabbed The Speed Of Trust as I hurried out to do the ballet lesson "taxi" run. I had balked at reading it, though I've come to recognize that some good insights do come packaged in pop-management books and I'm pretty good at speed reading through chaff. (And you, no doubt, have become well practiced at speed reading your way through this journal... hoping to find some calories and cholesterol in amidst all this fiber. See, this is what I like so much about my audience—you're full of optimism. You read this piece, and ever since, you've been full of hope, right?)

I'm a few chapters in and still feel somewhat reserved, but I'm coming around to feeling it was a serendipity to grab that book, given that I'd by a fluke stumbled upon Upshaw's brand integrity paper yesterday.

Some highlights:

Henry David Thoreau taught that "for every thousand people hacking at the leaves of evil, there is one striking at the roots." -- Stephen R. Covey, Foreword to The Speed Of Trust

Isn't that where architects should be working—at the roots? And it is, when they can tackle design issues strategically, rather than being backed into tackling crises reactively.  

"Low trust creates friction... Low trust creates hidden agendas, politics, interpersonal conflict, interdepartmental rivalries, win-lose thinking, defensive and protective communication... Low trust slows everything--every decision, every communication, and every relationship." -- Stephen R. Covey, Foreword to The Speed Of Trust

and

Trust = Speed Cost

-- Steven M. R. Covey, The Speed Of Trust

Ok, I don't like seeing an "equals" sign in that relationship, but I have scolded myself for being pedantic. It is a schematic of a relationship that is important to reveal: Lower trust reduces speed and increases cost. 

This could be an emblem for agilists: more trust→more speed and less cost. Ah, but Covey also points out that trust is a function of competence and character. Even the most competent team can give way to the stories we tell ourselves about expediency and the necessity of now—this extraordinary moment. And sometimes it is fine, and we work off the debt, but when we don't, the debt mounts, and we wake up to find the storm is upon us.

Speaking of storms, Obama's words capture eloquently the tenor of our time:

"Yet, every so often the oath is taken amidst gathering clouds and raging storms...  

That we are in the midst of crisis is now well understood. Our nation is at war, against a far-reaching network of violence and hatred. Our economy is badly weakened, a consequence of greed and irresponsibility on the part of some, but also our collective failure to make hard choices and prepare the nation for a new age. Homes have been lost; jobs shed; businesses shuttered. Our health care is too costly; our schools fail too many; and each day brings further evidence that the ways we use energy strengthen our adversaries and threaten our planet.

These are the indicators of crisis, subject to data and statistics. Less measurable but no less profound is a sapping of confidence across our land — a nagging fear that America’s decline is inevitable, and that the next generation must lower its sights."

President Obama, Inaugural Address, 1/20/09

1/25/09 "Thank you for telling the story of James Madison"

A heart-warming snippet in Dana's email today:

"Thank you for sharing the story on the US constitution and enterprise architecture. I've just arrived, 4 months, in Brussels at the European Commission and today I made the connection between separation of powers and separation of concerns. A search on this led me to your story.

A great inspiration!" 

-- personal email to Dana, 1/25/09

Last week an architect "alum" was asking me for a Madison reference, which reminded me that we've stopped including the What it Takes to be Great executive report in our Software Architecture Workshop binder readings section. That's such a pity—we need to go to a separate readings book like the one we have for the Enterprise Architecture Workshop. Oh, I know, "no-one reads those things." But, I practice optimism too. Grin.

Anyway, I want to record Dana telling the story or reading the Madison piece from that paper for our Resources for Architects website. Dana has a great voice for that!

1/25/09 Doctrine and Principles

I'm wrestling my way towards another set of distinctions, this time in the principles, doctrine, values, space. I see lots of grey, and I'm trying to find the edges between the concepts, but they are murky. See for example:

Doctrine (Latin: doctrina) is a codification of beliefs or "a body of teachings" or "instructions", taught principles or positions, as the body of teachings in a branch of knowledge or belief system.

... doctrine is also used to refer to a principle of law, in the common law traditions, established through a history of past decisions, such as the doctrine of self-defense, or the principle of fair use, or the more narrowly applicable first-sale doctrine. In some organisations, doctrine is simply defined as 'that which is taught', in other words the basis for institutional teaching of its personnel about its internal ways of doing business.

wikipedia, as of 1/25/09

 The "principle of fair use" is defined as:

Fair use is a doctrine in United States copyright law that allows limited use of copyrighted material without requiring permission from the rights holders, such as use for scholarship or review.

wikipedia, as of 1/25/09

All of this is important to identity. Who are we, what is our core mission—these are integral to identity. But more, what values and principles define us, and what guides our decision making?

1/25/09 Procrastination Dilbert Style

Scanning through Dilbert comics (inspired by Charlie Alfred; but Charlie sure has a greater density of good Dilberts than Scott Adams!), I didn't want to lose track of these:

1/26/09 Architect as Consultant

1/26/09 The Importance of Play

Some time ago, I mentioned a company safety policy I had to sign at a client site that disallowed "rough-housing." Going in, that felt like a real downer, but fortunately it was not upheld to the letter, and the R&D community was as playful as one might hope. Now, I caught and gave Ryan a good "whoopin" this morning, and he got ready for school laughing gleefully. Covey argues that trust makes things quicker, but fun, and the goodwill it generates, makes things quicker too! Indeed, Ryan was ready without the usual crabbing about what a waste of his life school is; a net time saving and health benefits to boot. Over and over, I forget that lessonwith my kids, our dog, my work. Back up a littlethe dog? Yes, she loves a great big rough-housing family laugh-fest just as much as the kids.

Laughter and fun are important at work too. Now, I'm not advocating wrestling your team curmudgeon into a helpless position and "whoopin' him good." Still, it does call to mind: one of the things the SWI did for our monthly "Development Day" was bring in a team from a comedy sports club in San Jose, and they ran a day of fun team training. I'm no church lady (hmm, referencing SNL from a by-gone era dates one like rings on a tree, I'm afraid), but getting into and out of a spaghetti tangle with my colleagues stretched more than my muscles. Even so, we still use some of the "exercises" we learned in that eventmost notably, the flying fruit game. It's fun, and great lessons come out in the debrief about communication (applicable to distributed systems and system development) and teamwork.

Ok, so I'm not advocating playing "workshop games" at the top of every meeting either. That guy giving Happy Go Lucky a dunking for being too happyhe works in software development, I just know it! But, sometimes, when things look like they need a pick-me-up, it is just as well to have some tricks up your sleeve.

Now, you've probably used this, but if you haven't there's the Greg the Architect series on youTube. What else? Come on, what fun and funny tips do you have to share with the rest of us?

With the storm upon us, more and more we're going to have to play all our leadership cards to keep ourselves, and our teams, looking on the bright side, and embracing opportunity with enthusiasm so we create self-fulfilling prophecies that are good for all of us! Remember, leaders set the tone!

Over 70,000 people lost their jobs today. It's the work of Dementors I tell you. The trouble is, the "retail therapy" that was our usual solution, and which got us solidly criticized around the globe for our materialism, is being rethought, and there's a world of hurt in store.

[1/27/09]

"We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about." - Einstein

Not so fast, Einstein, not so fast. Our lifestyle is destroying the planet, but without the non-essential 90% of stuff in our lives, the wheels of commerce fall right off. And it's not impossible, but it is a lot harder, to be enthusiastic in a soup kitchen line. So, to turn this around, we have to turn the planet around. We need to not just put a band-aid on our carbon footprint, but fundamentally shift how we make what we make, use what we use, and get rid of what we no longer need. Then comforts and selected luxuries we can pursue, giving avenues to enthusiasm to all who create products and services that leave this planet and its people better for our presence, not worse.

A great big spending wave on "going green" would be good for commerce, good for our planet, and good for our sense of self, and breed enthusiasm a plenty.

([2/5/09: Upon review, I see that Charles Kingsley is also credited with the "all that we need to make us happy is something to be enthusiastic about" quote above, and since he came well before Einstein, I guess it would be better to quote Kingsley on that. But then I couldn't say "Not so fast Einstein"!)

1/27/09 Economics... and Artifacts That Amplify the Value

Yesterday I listened to Grady Booch reading his Economics of Architecture column from his IEEE Software series (a column by this title was published in print in 2007). It is richly insightful and vividly written. Alas, my focus suffered some for multi-tasking, and I want to return to it. I did dial in on a perhaps peripheral point though it stood out colorfully: it is important to create architecture artifacts and keep them up-to-date as the architecture evolves—if we don't, we rely too much on tribal memory which is too leaky and unreliable to trust the viability of systems that underpin our business to. [Especially when, given our now culture, our tribe typically leaves less of a graphic trace to support oral history than the Bushman did!]

Ok, I acknowledge, I want that point to be punched up, because I perceive that when the exhortation to "travel light" leads to scant out-of-date or no documentation, our complex systems teams are poorly served. It is possible to have structural integrity without up-to-date architecture documentation. But is it likely, and even if it is the case, for how long will this be so? And it is possible to have a thriving business without structural integrity. But for how long will this be so? Many teams get interested in architecture when the burden of their inattention is overcoming their ability to respond to the business, to grow, to embrace new opportunities, to move in new directions. Then the emphasis is on "recovering" the architecture, modularizing it, nudging it toward a structure that is more transparent and evolvable. It must be done, but it is hard-going at that point. It's risky, expensive, slow; like fixing the engine while driving at highway speed.

Daniel Stroe mentioned "Festina lente" (in a personal email) and it is such a powerful concept: Make haste slowly. Be composed when all around there is the urge to hurry. An architecture that allows for true agility, meaning responsiveness to the market, takes attention. Yes, explicit attention to the architecture, to the structures that will allow scale, that will allow the addition of features, that will allow innovation in product and process, to delight customers and create efficiencies. Haste makes waste. Ah, but make haste slowly! Not overly slowly, but with composure, so we do the right things, just enough, to ensure that we enable our business to be agile. That, after all, is what we're really after. Agile development is a good thing, if it makes our business agile; and not, if it bonds our business to the present, which drifts so quickly into the past.

Thanks Grady, and thank you Daniel!

Aside: Minimalist architecture is a core principle we articulated and advocate strongly. Minimalist is about the decision set. With teeth has implications for documentation. code warrior?

1/27/09 Bushman, warriors, ...   

I was looking for a sketch I'd done of Archman showing his son the architecture drawings on the cave wall of his tribal ancestors... didn't find it. I suppose that means there's a sketchbook waiting to be scanned in somewhere. But I found the code warrior... bugs circling, a saw to hack rather than cut code, Viking... it's the sort of thing that would get me lynched if it fell into the wrong hands!

That's so not a developer any of us has ever worked with, right? And it's certainly not an incarnation from my past. Grin.

Perhaps he'd best go back where he was—disguised as humor and clinging to hope at the bottom of Pandora's box!

[1/30/09: I thought ugh, taken out of context, that image is so potentially offensive I should remove it. Then I had a still more wicked image -- the Agile code warrior: as above, with a chainsaw (hack faster). But, of course, I won't go there. There are some who use the Agile brand to front a "quick-and-dirty" approach, but they are not following the spirit and the expression of the Agile values. No, such an image would be like tainting the artist by pointing to a poor imitation by an unschooled opportunist.

Oh, please remember, I'm assuming an audience with an intelligent and wry sense of humor! And one has to be allowed some fun! Just, shhhhh, don't tell Scott and don't tell any fake Agilists.

And yes, I am familiar with the origin of the term "hacker"! I'm also familiar with how it has come to be used.]    

1/27/09 The Most Important Thing

I came away from Obama's Inaugural Address going "great content," yet wondering what punch-line action I was supposed to have been inspired to take. I know I was distracted, and rereading the speech has been very rewarding. It is my habit, on holding a mirror up, to take a peek myself. And so I thought, ok, the key point I wanted people to get when I expanded on Grady's "truth to power" piece was "always be cognizant that it is a human being receiving your feedback." But I never made that one point. I danced around it, to be sure. But I didn't say it just like that, so it was clear that was my big point. When we give feedback, it is because we want to make a difference. So give the feedback in a way that makes a difference most effectively—in a way that takes into account the humanity of the person (or group of persons) receiving the feedback. And, in a way that takes our humanity into account.

Yes, if I were to boil it all down to one thing, it would be "remember the human being." A person in power is still a human being, with all that means. Hopes and aspirations about to be dashed by your feedback? Defenses about to be raised by your feedback? The human being. We introverts don't want to deal with all that icky soft stuff that takes time away from our "real" work. It would all be so much more efficient if we could just get by with everyone assuming positive intent, and interpreting our feedback from that frame of reference so we didn't have to be careful about how we gave it. But here's the rub: We may see that they're up a proverbial creek without a paddle, but how do we get them to take a paddle from us in time to avert disaster? And then there's our humanity: How much of their perspective do we understand? And their context? Their pressures? Their assumptions? Their analysis?   

So, I found myself realizing that I hadn't said what I set out to say with exactly the words that most clearly and memorably expressed my intent. I suppose that's Composition 101. Too bad I never took Composition 101!

Not that we want to toss the ice cream, of course. There's a place for content. And delight--a happy embracing of life; ice cream, if you like.

1/28/09 Embedded Software Architect Position

"I am looking for a Software Architect in North Carolina. The position requires embedded experience as well as Linux and C++. If anyone is interested they can contact me."

Amy Carmichael, www.itiselect.com,  acarmichael[at]itselect

For more information, see the Architect Jobs page on the Bredemeyer site.

1/28/09 Love Those Carrots!

"I have been using the Bredemeyer website for a while. Yesterday afternoon I noticed one of the articles I had not read yet (“Getting Past ‘But’: Finding Opportunity and Making it Happen”). Not for my surprise I found it superb. The article comes at a very interesting time when I have been questioning some of the aspects you describe so well in your article regarding ‘innovation trap’ and creativity."  

Simone Marsland, email 1/27/09

Thanks Simone! That cast a bubble of warmth around an otherwise cold day in Indiana. When you pour passion into something, doing it should be reward enough, right? Getting to do creative work is certainly a privilege I recognize and value. Yes, it is rewarding to work hard on something, to have generous and insightful thinking partners work hard on helping you make it better (thanks Charlie and Kristen), and to feel like you did a pretty decent job. But you're still not sure, because value is in the eye of the beholder. So it is very rewarding to have architects write, from time to time, and say that what we did was helpful—superb even! Wahoo!

Don't worry, a carrot or two on a stand-out week won't go to my head. And nor will any carrots you are hereby inspired to pass on to your colleagues.

"Goodwill is the silver bullet."   -- Dana Bredemeyer  

Goodwill? I mentioned goodwill here, and here, and here.

1/29/09 FollowSite

Since this journal is updated so frequently, an RSS feed on it would be very noisy! Likewise, you certainly don't need to track changes to it on something like followsite—but I mention followsite because you might find it worthwhile to track the Bredemeyer Resources for Software Architects site. As for delicious, stumbleupon, reddit and the like, I realize you don't need to keep track of where to find me, but it would be kind to me if you'd bookmark my journal site, and our Bredemeyer Resources for Software Architects site.

1/29/09 Principles versus Postulates

Ok, add postulates to principles, doctrine and values in the identity terminology soup! Mark Lane (indirectly) brought Easton Rhodd's "Enterprise Architecture Postulates, Principles and Objectives: Finding the Discipline" working paper to my attention.

"In traditional logic, an axiom or postulate is a proposition that is not proved or demonstrated but considered to be either self-evident, or subject to necessary decision. Therefore, its truth is taken for granted, and serves as a starting point for deducing and inferring other (theory dependent) truths." wikipedia

1/29/09 The Code is the Truth

Grady Booch has received some enthusiastic head-nods from developers for his "the code is the truth" phrase. It's catchy and there's truth in it... and still I feel uncomfortable with that being the phrase that gets ping-ponged around. For the truth in the code interacts with the environment, and with other code, and you have to know more than the code that is in front of you, to really know "the truth."

If we look at any code snippet, can we tell if it will be fast? useful in only one context or across many contexts? robust? The truth, if you want it, is that many system properties are emergent not just from system evolution, but from interactions within the code and with the environment. Arnon Rotem-Gal-Oz's 1/14/09 blog post illustrates very nicely the context-sensitivity of the "truth."

So we start to teeter on the point that the code is the truth, and shade into the code is not the whole truth (Grady Booch, cnet). And it is very hard (to arguably impossible for large systems) to get our arms wrapped around all the truth held in the code when we have just the code to work from. Structural analysis tools help see some of the hidden truth—hidden because the code-as-truth can be a rather long-winded telling of the truth we're interested in. Performance analysis tools help, because they reveal what the code by itself does not—what comes of interactions with the environment.

And keeping an up-to-date set of architecture views and documented decisions along with their rationale, justification, explanation, assumptions, etc., helps.

Of course, there's the rub. Up-to-date. That's where this "code is the truth" thing originated and gained such enthusiastic energy! We let the architecture (documentation) get out-of date, so that it does not map to the truth in the code, and we cannot trust it.

This is why I've talked about the bigger truth that is in our organization (roles and responsibilities) and process. Unless we make it a responsibility to maintain the architecture-as-truth, it is very hard for us to leverage the truth that is in the code, to wield it for good.

If the code is the truth but not the whole truth, the architecture (documentation) needs to reflect the whole truth in strategic terms. Strategic terms. Terms that take the business and the environment into account.

Then the question is, should the architecture (documentation) follow the code, abstracting, rationalizing and contextualizing the truth? Or should the architecture create the truth that the code expands upon? Or some of each—intentional and emergent?

Yeah, yeah, you know what I think. But I'm still trying to figure it out! Grin.

1/30/09 Caveat Lector

Which serves to remind mefrom time to time, I use Grady Booch's writing as a springboard to expand or (re-)organize my thinking. Of course, if we had access to all of Grady's thinking, mine would be (still more) redundant. So, by Yang I only mean I'm filling out my cognitive space, and imply nothing about anyone else's, and particularly not Grady's!

1/30/09 Down to the Wire!

Ok, you've marked your calendar and you're going to send your kind words of celebration and support on February 3, right? Right? What are we celebrating? This journal turns 3 on Feb 3. Oh well, as I said last year: maybe next year... Grin.

Thank you Charlie for not letting the event go unmarked; it is amazing to me that someone I admire so much reads my journal from time to time. And thank goodnessCharlie's input to our Getting Past "But" report, and to my thinking about complexity, value modeling and architecture more generally, has been invaluable! Daniel, you got a head-start too, and your Thanksgiving note stands out from all the kind words I've received in my career; thank you. So often, with just a few words, you have shifted my worldviewand that is in masterful contrast to my so-many words!  And Clayton, thanks for the "brain architecture" tribute to my "architecture on the brain."

And thank you (again) to Grady Booch, whose blog inspired this journal. I had been following Grady's blog for quite some time before the coin dropped—he'd created a permutation on the blog theme that I liked: journaling on his site, and piping his entries to his IBM DeveloperWorks blog. Well, I didn't want to pipe journal entries to a blog, because I like (no, definitely need) to be able to edit my entries, and the blogosphere ethic disallows that (for good reason; you don't want to change the basis for discussion once a discussion is under way)!  So my planned permutation was to mine this journal for interesting bits to craft into blog entries, and I have, on occasion, followed that plan. Anyway, Grady's modus operandi—-the form it took and the vivid and often personal quality of his online journaling—inspired me.  

The rest of you who remain nameless, thank you for making me both more shy and not shy enough!

Anyway, thank you for letting me practice being me, and giving me the grace of your company.

1/30/09 Upcoming Workshops

If you know anyone who would be interested in these workshops, please do let them know so they can get a seat in the case of the Software Architecture Workshop, and take advantage of the discount in the case of the Architectural Leadership Workshop. 

As many of you are know, our workshops attract a very fine set of architects, which makes for a great experience at the time, but also creates a strong network of talented peers. Our Architectural Leadership class runs internally almost as often as our other workshops, but just takes a bit more time to get traction when it is an open enrollment class. So, it'd be great to have your help getting the word out about it!

1/31/09 Ah, Now I Get It!

Ryan is into combat flight simulator. This morning, for mars, he dropped all his bombs and flew under them to see if he could take himself out. He did too! Walla: I now understand what all these layoffs are about! Let's see, cut our labor force so the unemployed aren't spending and the news freaks out everyone who still has a job so they stop spending. Boom! Shot right out of the sky by our own bomb!

I wrote more, but I got so sick of myself I ripped the piece! So, make what you will of the metaphor. I got a kick out of it.

[2/1/09: Fortunately Charlie stepped in:

"You did a nice job of looking at the system dynamics from the business’ perspective.  The business is motivated to lay off people to cut expenses, but fails to see the ripple effect coming back as a reduction in sales.

I told my wife something similar, a few months ago – back when there was a lot of discussion of the merits of tax cuts, tax credits, or stimulus packages.  I asked her,

“How many people are going to use the stimulus check or tax cut to pay down debt, or sock it in the bank because they are a afraid of what the future might hold?”

Such stimuli fail to achieve their goal of giving the economy a jump start by stimulating spending, because too many people have strong incentives to do anything but spend the money.

This is “the border” where microeconomics meets macroeconomics.  Nobel-winning economist Paul Samuelson said, “microeconomics tells us that any given farmer improves their profit by growing as many crops as possible, but clearly this statement cannot be made for all farmers.”  In microeconomics, the key assumption is that the individual (consumer or business) has no effect on the whole.  In macroeconomics, the sum total of the behaviors of all individuals are the whole.

So, what this all goes back to is the admonition to “think globally, and act locally.”  If a thought or motivation occurs to you, the same thought or motivation may occur to thousands or millions of others who think like you.  This awareness of systems dynamics needs to enter our collective consciousness, stay there, and motivate behavior.

Architects are trained to think like this, when they consider things like tradeoffs, risks, contexts, and system evolution.  In fairness, some stakeholders and developers also think this way, but many do not.  Conceptual distance makes people think locally and act locally (but with global side effects).  It is the responsibility of the architect to help local thinkers understand the bigger picture, and make decisions in a way that helps increase aggregate value."

-- Charlie Alfred, personal email, 2/1/09

Ah yes, would that every CEO would put that "cautious foot on the spending brake because aggressive cuts will put more spin in the downward economic spiral."

"These businesses will have realized that the risk of doing the same old thing is greater than the risk of trying something new. I think the these are the ones that will lead us out of this recession.  It certainly won't be Chicken Little."

"recession survival tactics" blog post, Tom Fishburne, 1/31/09

 


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