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

Trace in the Sand
Architecture Journal

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

July 2007 By Topic

- Teaming across Disciplines
- Architect Job Listings
- Architect(ure) Links
- Properties of Time
- Agile Architecting and Business Agility

- Storytelling and Leadership
- Leadership in Movies
- Requirements and Architecture
- Essential Design Upfront
- Architecture Workshops
- More Movies
- Social Intelligence
- Myths of Innovation
- NDepend

 

 



July 2007

7/11/07 Architecture Notes from Prior Months

I jot architects/architecting/architecture-related notes (those that don't relate to client work) in this "journal."

You will find my architecture journaling from past months in 2007 at: June, May, April, March, February, January. And from 2006: December, November, October, September, August, July, June, May, April, March, February

HelpMatch Call to Action

7/11/07 A Complete Break from Architecture!

We took advantage of a break in our client work schedule and headed West. Kayaking/fishing/exploring/camping in the Grand Teton and Yellowstone National Parks was splendid!

I do love the rugged western mountain country. The traffic around Denver was horrid, and made me grateful for my quiet commute to/from Indianapolis airport. But the breathe-taking mountains, rivers, lakes and canyons of the west have great draw for me. It's country to repair the work-worn spirit all right!

I don't believe I had a single thought about architects/architecting/architecture for the entire duration. But, I'm back!

Sometimes... function follows form.

7/11/07 Architectural Leadership and Other Skills

I have a What it Takes to be Great: The Role of the Architect Workshop coming up in Chicago next month. Naturally, I'd like to see you in Chicago, and we do still have 6 places open [7/24/07: make that 4 places]. But you could instead look at the Grove workshop schedule for visual strategy and graphical facilitation workshops.

I'll be focused on rev'ing our Role of the Architect materials over the next couple of weeks, so if you want to help other architects complement their talent and experience with exposure to new idea-sets, do send me your recommendations, links, stories, etc. I'll be updating the Role links on the Bredemeyer Resources for Architects web site as I go, so everyone will benefit if you generously share what material you have found helpful as you work on your architecting skills.

Along the lines of sharing experience to improve and enrich our software discipline, Michael Nyard tells a story and advocates considering architecture "even in agile projects." Another of my favorites for sharing lessons bred of experience is Dan Pritchetthis Adding Simplicity blog isn't the most active blog on the block (he's a busy architect, an EBay Technical Fellow, and an active father, so I don't hold it against him), but I find it one of the most insightful (being a busy architect, an EBay Technical Fellow, and an active father, I fully expect it of him).

7/11/07 Teaming Across Disciplines

I liked this story about fostering creativity by facilitating dynamic teaming at Microsoft. All of us who care about "process" in software, really are trying to get at more effective, collaborative, collective work. I've said that I know architecture is fully supported when the architects have a dedicated meeting room (wall-papered floor-to-ceiling with white board is optional—paper works too).  I'm being somewhat glib, but it hits close to the bone for some groupsmeeting rooms are so scarce in many organizations, that dedicating a meeting room to an architecture team can be more of a sacrifice than dedicating people's time! But this takes the idea still further, and having the entire work area wall-papered with whiteboards is totally neat!

Imaginethe architecture models on the walls all around the development team's work area. Of course, some people would be concerned about visitors seeing the architecture models, but we all know that the architecture models don't stand alone. They need explanations and defense. Lots of defense! And connected dots, tying the decisions to the architecture drivers, the qualities and strategies, and the history, that makes the decisions make sense for the system under design and development.

But again, imagineif the architecture models were that accessible for all to see, talk about and contribute to, what a difference that would make not just to the dynamic nature of the validation process, but also to the development organization's understanding of the architecture, and the shared sense of ownership of the architecture. The whole group would be drawn into it, vest themselves in making it great, embrace and defend it.

That would breed a special kind of competitive advantage that would hard to duplicate, if only because it is unusual to be so open and so bold.

7/12/07 Architecture Blog Links

Role of the Architect Blog Links

7/13/07 Pink and Blue

Last night I read Zoe Hart's "pink and blue" post (July 6) on Chasing Glaciers. It's a lovely piece on assumptions! What also struck a chord for me, was the use of color to avoid gender stereotypes and still have the conversation about larger-group predilections. I've found myself reverting to a similar use of "pink": 'I find myself preferring the more “pink” approach to leading change by motivating and facilitating, rather than engaging in power struggles' (email to a friend, 6/15/07). But, I'm afraid, that is going to have it's own sort of backlashI see way too many "pink" books in the management/leadership section of bookstores. Altogether, I think this is going to be an interesting time, with its share of difficulties, as we figure out how to have the discussions and learning we need to have about style differences, without creating or reinforcing limiting expectations around either style or gender.

7/23/07 Architect Job Listings

I added the following job listings to the Resources for Architects web site today:

7/24/07 Architects/Architecting/Architecture Links

Enterprise Architecture Links

Architecture Links Blogs

Innovation Blogs

And for something pretty cool (you may even drive away in a new Volvo today): Lessons in Scandinavian Design. Lesson number 3: Form follows function; Lesson number 1: Less is more. And so forth.

7/24/07 The Properties of Time

Pam Lamont brought this quote to my attention:

"Time is that quality of nature which keeps events from happening all at once. Lately it doesn't seem to be working."

anonymous, quoted in Time Management for New Faculty, A. Ailamaki and J. Gehrke, SIGMOD Record, June 2003

I second that!

Here's another quote from the same paper:

"Time is a great teacher, but unfortunately it kills all its pupils." — Hector Louis Berlioz.

7/24/07 Agile Architecting and Business Agility

Oliver Degnan asked me to pull together my thoughts on agile and architecting. First, there's agile architecting and then there's architecting for agile projects, and architecting within agile projects. The Agile Manifesto articulates the following core values:

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan

The Visual Architecting Process certainly values individuals and interactions, stakeholder collaboration, and responding to change; indeed, the process is built around these values, and built around learning as fast and as cheaply as possible from individuals and interactions and stakeholder collaboration—and models and visualizations to facilitate individuals as they interact and collaborate!

As for documentation, the Minimalist Architecture Principle also pushes back against "comprehensive," but recognizes that some decisions needs must be made with the system goals in mind. These decisions impact contributors across the scope of the architecture, and this means that communication (and the documentation that supports communication) and recording and working in alignment with the decisions are important.

The Visual Architecting Process is an agile architecting process, from the point of view that the quick iterative cycles build in collaboration with key stakeholders. These include, but are not limited to, customers. For example, the goals and concerns of operations teams, the sales team, customer care, marketing, QA, and other internal business functions, as well as strategic management, acting with the stewardship of the company and shareholder concerns in mind, are taken into account and balanced along with the goals and concerns of various stakeholders in the customer space. The latter include end users as well as purchasers, IT groups, and so forth. For a product team (whether you're talking Google's systems or shrink-wrapped software, or products like printers or cell phones), there is a complex set of stakeholders, and a complex set of goals, expectations, needs, and concerns, as well as constraints and challenges, that all have to weighed and prioritized and factored into the architectural design/decision making process. For a company that builds a set of products (in a product line/family or integrated solution), issues of integration, consistency, integrity of identity, as well as leverage to increase productivity, innovation and return on investment across the product portfolio, broaden the trade-off space still further. If you find it difficult to parse the sentences in this paragraph, you've experienced only a glimmer of the complexity of the decision space!

Yet the Visual Architecting Process integrates design techniques that help "Pareto" the work, striving for 80% or better design information with 20% or less of the effort. That's a high goal, and we go after it by bringing the values and principles that underlie agile development to the architecting process. However, in advance of working code, the process produces visual models (along with supporting explanations and rationale) that are used to validate architecturally significant requirements and architectural approaches with key stakeholders.

Short iterative cycles, early involvement of stakeholders, and visualization, allow for quick learning, early direction setting and iterative direction correction and refinement. But this learning is done with models as long as they are effective, reducing the cost of change as the architectural design is explored, refined and elaborated. Along the way, the architecture is documented, both to aid the architects in thinking through approaches and alternatives, and as a communication tool to get feedback during validation from a broad set of stakeholders.

The process promotes early discovery of opportunity to innovate and differentiate, and builds alignment and motivation through a strong, shared vision and high-level system design that identifies system building blocks that, for large systems, become the units of agile development, allowing further innovation and experiment, with generally lower cost of changelowered by isolating the impact of change.

This process then, allows us to integrate the best of agile software practices along with other practices used to get complex products created in reduced timenamely, allowing more people to be effective, productive and creatively engaged in building the system, because they have clear commitments to and from the system via the system design, and, yes, its documentation.

Of course, I've been on this soapbox before:

And I've defended architecture documentation various places:

Also related:

... so... that's wordy and first drafty... but I'll put it "out there" to encourage reaction and feedback to help me improve the positioning and explanation of just how the Visual Architecting Process is an agile process, how it supports business agility (the true goal), and how it supports doing agile software development on large projects, not just small projects.

added 7/27/07: On Agile and Documentation

and while I wouldn't toss the proverbial baby out with the bathwater:

7/25/07 Architecture Workshops

I have posted an open enrollment Software Architecture Workshop on October 1-4, 2007 in Arlington, VA (across the river and just a few subway stops from Washington DC). We also have an open enrollment Enterprise Architecture Workshop on October 23-26, 2007 in the same location. Dana will the teaching the EA workshop. 

There is a discount for early enrollment, so if you know anyone who might be interested in either workshop do let them know. Actually, we're so tight for weeks on the schedule over the rest of 2007, that if we don't get a flurry of enrollments pretty soon, I may be forced to withdraw one or both of these open classes just to free up time for in-house work. I have a soft spot for the open classes, as they pull together architects from a broad set of industries and that makes them quite different from the in-house classes (which I enjoy for a different reasonwe get to go into more competitively sensitive areas). 80% of our in-house work this year is with clients we have worked with before, and that is usually the case, year-to-year. So the open classes also give us exposure to architects from a wider cross-section of companies.

7/26/07 Architects/Architecting/Architecture Links

Strategy Links

Technology Watch

7/26/07 CIO in your sights?

As you brush up on business skills to complement your technical skills, it might be interesting to note that, for some, the combination is drawing headliner compensation packages—see When the CIO earns $9m. This was interesting:

"Not surprisingly, financial services firms (including banking and insurance) dominate this year's ranking with 15 entries, so dependent is that industry on technology to operate and innovate. Retail is second, with 11 executives on the list."

Kim Nash, When the CIO earns $9m, Baseline, July 17, 2007

On the downside: in only 52 out of 1000 companies, CIO's showed up in the top 5 most highly paid executives.

I've always talked about technology roadmaps as a key architecture artifact, but to raise the state of the practice I've started to be more bold and blunt, telling architects it is one of those things I expect and look for as a distinguishing hallmark of an architect. So, this use is interesting:  

"Tim Shack (No. 7, $5.9 million), CIO at PNC Financial Services Group in Pittsburgh, meets with the company's board several times a year to describe business projects and the technology behind them and provide regular updates. Last fall, PNC's board met for 3 hours specifically to discuss emerging technology trends that might affect the company, Shack says. "You know those Consumer Reports ratings—the little circles filled in all black or half black? We did those to assess where we think we are and how each business unit is positioned against trends in the industry 12 months and three years out," he says.'

Kim Nash, When the CIO earns $9m, Baseline, July 17, 2007

7/26/07 Storytelling and Leadership

7/26/07 Organizational Effectiveness

7/28/07 Leadership Moments in Movies

I Googled my way to Derby Management's Everything I Know About Leadership, I Learned from the Movies piece (this appears to be quoted without acknowledgment by Naren Kini), and it reminded me of The Bridge Over the River Kwai which I saw only once, long ago. I'll have to watch it again, given Derby Management's observations:

"Which is all well and good, but of course the best interests of the British army are not served by helping the enemy improve its supply chain. Obsessed with honor and with the vision of his own legacy, Nicholson never asks the most important question: Am I doing this for myself or for the organization? Execution takes priority over strategy. And when that happens, in business as in war, the results can’t help being catastrophic."

Everything I Know About Leadership, I Learned from the Movies, Derby Management, April 11, 2007

Given Derby Management's points about Dead Poets Society, perhaps Emperor's Club fits the bill more closely? I also liked Amazing Grace, and would put it alongside Elizabeth, but Amazing Grace isn't released on DVD yet (although in the UK, it'll be released on DVD on August 6th).

7/28/07 Architecture and Requirements

Since my insistence on "journaling" doesn't allow direct commenting, Charlie Alfred emailed his contribution to the discussion:

"I just read your blog post discussing Agile Architecting and Business Agility, and wanted to comment on the interplay between architecture and requirements.

As we’ve talked in the past about this subject, I know you realize that this is one of my favorites.  There is a great deal of misunderstanding in our industry about this subject, and I believe that this is rooted in two things:

  1. Confusion about what requirements and architecture are

  2. More confusion about scope, and how it relates to “systems of systems” (systems in the general sense – automated, organizations, etc.)

In their book Software Factories, Jack Greenfield and Keith Short make the astute observation that requirements are not statements about the problem, but rather are statements made by stakeholders about what they expect the solution to look like.  In his PhD thesis, Roy Fielding, one of the key architects of the WWW, wrote that architectural decisions are constraints on the design and implementation.  This is interesting, because it asserts that some requirements force architecture decisions and some are also architectural decisions, but it does not go as far as saying that requirements drive architecture.

This is where the second point about “systems of systems” becomes critical.  Architecture is an inherent property of a system, defining how that system is organized, how it operates, and how it adapts to change.  However, when we talk about requirements, it is critical to understand in which system the requirement originates and which system(s) it constrains.

If I am designing a new product, that product is my target system.  However, that product will be deployed into some environment, where it is expected to play a role and provide a source of value.  For instance, my product might be a speech recognition system, and the system into which it is deployed might be a radiology department of a hospital, which uses it to dictate exam reports more efficiently.  Further, the radiology department organization is also part of a larger organization – the hospital.  The hospital, in turn, may be part of an Integrated Health Network, etc.  From another point of view, we have the relationship between the project team which develops the target system.  Further, that team is likely to be an integral part of a larger business, which might be part of a conglomerate,

Now, when a requirement is asserted, we first have the question of where it originates.  HIPAA is a law passed by the U.S. Congress, administered by the FAA, which applies to health care organizations.  As a result, it also applies to departments of health care organizations and most likely the products they use to provide health care.  Furthermore, these requirements are mandatory, which means that the system must address them.  How it addresses the HIPAA regulations will lead to one or more architecture decisions.

Other requirements may originate in other scopes:

  • The hospital may require that the speech system support HL7

  • The radiology department might require that the speech system support electronic signatures

  • The development organization might require that the system provide remote diagnostics

Some requirements don’t originate outside the system.  The product’s architect might decide that the system be implemented in Java because of the support for JMS, or the availability of Java developers.

In summary, requirements originate at various system scopes and apply to some other set of system scopes.  Requirements might come from the deployment environment, from an authority that regulates the deployment environment, or from the development organization.  This is where things get dicey.  Sometimes a requirement is really a strongly worded suggestion, preference, or expectation.  The target system might not choose to, or might not be able to satisfy the requirement as stated.  This is where negotiation comes in, and there are several reasons why it is critical:

  1. The development and deployment organizations don’t always have the same interests or needs.

  2. The “typical” deployment organization is a myth.  There are many.  They operate under different sets of conditions and different business strategies.

  3. The individuals in these organizations have different likes, dislikes, risk tolerances, etc.

In other words, requirements are not only scope-sensitive, they are also context-sensitive (conditions), and value-sensitive (utility).  Architects need to know these things, because without them it is extremely difficult to properly manage tradeoffs and mitigate risks.

So it always cracks me up when I see a nicely formatted list of requirements, with no information about scope, context, priority, or value sensitivity.  Because that pretty much guarantees an awkward set of questions and a very interesting set of follow-on discussions."

Charlie Alfred, email, 7/28/07

Thanks Charlie!

I alluded to the complexities that arise from various system scopes, though it is true I was focusing on use contexts, each of which surfaces differing stakeholder needs/goals/concerns as well as environmental conditions/constraints. Even when we set out to add features to an already fielded system, we face uncertainty in many dimensions. As I see it, Agile is geared to addressing the emergent nature of requirements, emergent because our understanding a priori is flawed.

This all speaks eloquently to the need to involve architects early in the process, partnering with marketing and business or requirements analysts to surface/understand what the product/target system needs are and to articulate how to address them. There is at best a fuzzy boundary between where the statements about goals/needs end and where the solution design begins. But the point I'm trying to get at, is that the needs and the approaches to addressing the need are best tackled iteratively. This is not just a head-nod to agile practices. This is founded on the recognition that our understanding about opportunities to differentiate, and to efficaciously deliver on baseline expectations, emerges. Yes, as we work with an evolving set of models of both the product/target system (addressing value propositions) and its architecture (addressing challenge inherent in delivering on the value propositions) all the stakeholders involved get a better sense of the goals and needs, as well as a better sense of how to address them in a unique and compelling way. A way that differentiates; creates competitive advantage.

VAP, then, puts together multi-functional teams and iterative exploration, elaboration and refinement, and visual models, along with focused early dives into code, to quickly clarify both how we will compete with this product/system and how we will build it—value and challenge. Like other Agile processes, VAP is nothing without great people. But great people, working together to address value to their business and their customers, can accomplish great things by luck and heroics, or by focusing on the right concerns at the appropriate time. VAP just gives a name to the practices many great architects have naturally led their teams to work through. The name is only there so that we have a handle, a means to refer to these practices. We balked against a name for a long time, but it was because clients were defaulting to calling this set of practices the "Bredemeyer Process" that we yielded and gave the architecting process a name that places emphasis on the heart of architecting—the visual models that create a shared mind-space for the team. But as processes go, it is highly fluid. It relies on the good sense and experience of the architect and the multi-functional team to surface opportunity and explore approaches. Yes, it provides guidance, techniques, practices, principles. But fundamentally, it is the architecting process—the process architects re-invent and adapt, to create great architectures, to create great systems.

7/20/07 Charlie's EDUF (Essential Design Up Front)

"I have a couple of additional thoughts on the comments you added.

First, an agile approach is important for precisely the reasons you mention: the problem is typically too complex to tackle all at once, it changes as the solution process moves forward, and consensus (which requires shared vision and understanding) must be developed across several stakeholders.

The one caveat that I’ll add is that agile approaches, especially as applied to software development, has a bias toward focus on immediate concerns.  Martin Fowler had a post in his blog (http://martinfowler.com/articles/evodb.html#id2249653) which talks about this:

One of the primary features of agile methods is their attitude towards change. Most of the thinking about software process is about understanding requirements early, signing off on these requirements, using the requirements as a basis for design, signing off on that, and then proceeding with construction. This is a plan-driven cycle, often referred to (usually with derision) as the waterfall approach

Such approaches look to minimize changes by doing extensive up-front work. Once the early work is done, changes cause significant problems. As a result such approaches run into trouble if requirements are changing, and requirements churn is a big problem for such processes.

The key concern here is the tradeoff between the cost to create a robust design, vs the cost to adapt the design as you go.  So where does architecture fall, compared to development?  In my experience, different architecture decisions have different levels of difficulty to refactor.  Adding Web support to an application which was designed to support local client UI’s) is likely to be much harder than changing the logging strategy.

One of XP’s goals is to avoid big design up front (BDUF).  While I agree with that goal, I don’t believe that it equates to ignoring everything that is not directly part of the current iteration.  I think that there are certain future things that you must think about now, so I favor an approach I call EDUF (essential design up front).  This approach is sort of like applying the principles of defensive driving to architecture, and its keys are:

  • Focus on the immediate problem as Agile recommends

  • Simultaneously, think hard about where the problem might go.  This is very different from thinking about where the architecture might go.  A defensive driver watches the other vehicles and listens to traffic reports, but doesn’t necessarily act on all information.

  • Identify the situations that will be difficult or expensive to recover from an incorrect decision

  • If those situations are not “immediate concerns”, then figure out what kind of insurance you can buy rather than address the risk directly.

For example, suppose an application only needs to support local clients.  If you anticipate that remote clients are possible, you recognize that the parts of the client and server that do the heavy lifting need to be isolated from the parts that communicate.  You also recognize that security concerns are different in the two cases.  EDUF says that you can anticipate the problem and design defensively, rather than try to solve the whole problem at once."

Charlie Alfred, email, 7/29/07

Thanks Charlie. Not only is there the experience that "different architecture decisions have different levels of difficulty to refactor" but there is also the matter of perspective and responsibility. The architect has responsibility for the overall system, and perspective across the system. Component/service developers have a more narrow field of view, and even if, ultimately, they are responsible for systemic properties of the system, they are first and foremost, and most visibly, responsible for delivery of their component/service. This has implications for the scope of refactoring that is natural on larger teams, and still more so for distributed teams. So, it behooves us to do what we can to refactor and improve the architecture as much as possible before the structure is hard-cast in code; to learn more cheaply about requirements/expectations/opportunity to deliver differentiating value and to lower the cost of baseline utility. For we have this impression that software is mutable in a way that physical product is not. Yes, we clone and go, or, more aptly, clone and grow. Mutable. We accommodate change. Mutable. But, generally speaking, each time we mutate the code, we raise the cost of change. In physical system design, the cost of being off on the design, the cost of design change, is observably high, so we invest heavily in design tools and design practice. We run car designs through CFD simulations before even a prototype is built and run through wind-tunnel tests. And so forth. If we were more clear about the costs in the software lifecycle, the cost of (poor) quality, the lost opportunity cost of systems that become harder to change with each change that is accommodated, I expect that we would come to value ever more highly the EDUF approach. More likely though, it will simply be competitive edge that sways the pendulum of dominant practice back in the direction of EDUF.

Big projects can be tackled as small projects, as long as there is good (to great) context and strategy setting and dependency management. This takes architecture. And Conway's Law says, if the architecture of the system and the architecture of the organization are at odds, the architecture of organization wins. So, we need the architecture of the system, to co-design the architecture of the organization that will build it. For Waterfall 2006, we joked about submitting "Cascades: how to make waterfalls agile. YUP, you need architecture for that!" But for complex systems, and complex organizational situations (multiple vested interests, distributed teams, etc.), we need to invest in EDUF—and I see requirements and architecture as being two essential and highly complementary facets of "design." Facets that, in building architecture, aren't so unnaturally split into separate islands of work as they too often are in the software field.

Mark Twain on Agile (grin): Never put off until tomorrow what could just as well wait until the day after tomorrow.

quoted in The Classic Touch: Lessons in Leadership from Homer to Hemingway, by John Clemens and Douglas Mayer (appears on p. 45, see Google book preview)

7/29/07 Movies and Leadership

I've been reviewing movies looking for quintessential leadership moments. Why? Movies are seen by such a broad audience, that these moments become woven into our cultural lore; highpoints in movies become a shorthand entry in the journal of our collective experience. When we have but minutes to inspire, to change attitude, to shape expectation, we have at our disposal, this treasure trove of shared experience to draw on. But, alas, this treasure trove is full of uncut gems, and I'm looking for just a few that suit my purpose... So, in short, if you have movies (and scenes) you have found useful in developing your strengths as an architect, or to lead your team, please do share them with me!

I did Google further and found David Drury's "Popcorn Leadership: The Best Leadership Movies of All Time." While David, and the management classes Derby Management refers to, use these movies as a learning ground, my purpose in this instance is more focused. I want to draw on lessons we already have at hand, but do not necessarily hold in full consciousness, or lessons that we have learned en masse, and can therefore draw onlessons which hold all the emotive power of a shared story. This use is very much the use that John Wood put the classic "finest hour" scene from Apollo 13 to.

BK, I was much more up on movies than I am now. Of course, I'm pretty well up on movies rated G, and even some rated PG, and I'm quite well up on children's literature. And there even are some relevant (to architects) moments in children's literature. "Everyone has their own agenda" from Walk Two Moons still rings in my ears (we listened to the audio version on a road-trip)! And I've seen another message from Walk Two Moons showing up in leading-the-leader blogs: walk a mile in their moccasins.

Anyway, I haven't seen any of the Harry Potter movies, for as soon as Ryan and Sara hit the age to introduce them, I know I'll see (or, more accurately, hear) them ad nauseum. But then I stumbled upon Manda Rooser's reference to The Magic of Leadership: An Exploration of Harry Potter and the Goblet of Fire as a source of lessons "in decision making, risk, power, and ethics." All of these are key themes in the Role of the Architect workshop.

I need to (buy and) read Movies to Manage By: Lessons in Leadership from Great Films, by John Clemens and Melora Wolff (see this on Google books for a preview of the content).

I had put some movie picks on the Bredemeyer Resources for Architects website, but this needs to be updated... Daniel Stroe is responsible for these making it on the list:

You too, could be responsible for bringing new movie fare to this list. I have a backlog of movies to watch, mostly because my kids get first dibs on the projector—truth be told, I'd rather work, read, write, hike, bike or kayak, anyway. But, once in a while, I do kick back and watch a movie. Like, say, once every month or two...

7/29/07 Amazon is Down!

Sunday, 3:30pm East Coast time, and Amazon.com is down. Wow! And there's not even a Pacman game to play! What, this contingency was not thought through? ...   ... Oh well, it was back up in minutes.

7/29/07 Emotional Intelligence and Social Intelligence

Tracking from empathy (walk two moons in my moccasins) to other components of emotional intelligence, I stopped by Daniel Goleman's blog, and scanned his more recent work on social intelligence. I thought this was important for us to keep in mind:

"When it comes to doing our best at work ... there are surprising consequences from our relationships. The brain has an optimal zone for mental efficiency, which lets us excel in whatever we do. But that zone turns out to be fragile – and our interactions can knock us out of it or keep us in. Emotions are contagious, and they flow most strongly from the more powerful person in a relationship. So a nasty boss or threatening teacher can create enough distress to keep us from that zone, while a supportive leader or encouraging teacher can help us stay in it.

... The bottom line: nourish your social connections."

Daniel Goleman, Social Intelligence, A Quick Introduction

and it brings to mind Alistair Cockburn's Dance of Collaboration, especially the piece on "Lift Others." I also like Brian Sondergaard's piece on The Proactive Architect (July 18, 2007).

Scanning around further, Goleman has this to say about email and group decision making:

"As with much about human social capability, the problem is magnified in group conversations. E-mail is a wonderful medium for distributed conversation but a terrible one for group decision making. Our mind blindness doesn't just deny us the ability to read the speaker, it takes away our ability to read other listeners as well. This creates challenges for IT organizations that are trying to implement distributed collaboration environments.

...

Although claims that telecommunications will replace travel have persisted ever since AT&T proposed the videophone in 1964, technology is a complement, rather than a substitute, to meeting face-to-face. People communicate better when they are together, and they also communicate better online after they've spent some time one-on-one. The memory of what a person is like in the real world mitigates the mind blindness created by our online tools."

Web Rage, by Daniel Goleman and Clay Shirky, CIO, June 28, 2007

This complements my observations:

But I've been getting anxious that as a technical community that has matured in the age of email, we rely far too exclusively on email [and wikis] to get understanding and buy-in to our architecture approach. We complain of being meeting-ed out, and claim that email does the deed well; we like that it is asynchronous. But therein lies the danger. A number of people I know read email, but they don't respond. You don't know if they've read the email, and if they did, you don't know how they took it. Face-to-face, or at least voice-to-voice, you're more likely to get feedback, both verbal and non-verbal, that will give you get a better sense of whether they're getting your message—understanding it and being inspired by it. And you will get better input; input that will help you create a better architecture and more influential end-to-end story that connects concerns with architecture decisions.

my comments on The Tipping Point, February 4, 2006

But I in my neuroscientific naiveté, I assumed flaming was driven by the rewards to the nucleus accumbens from punishing a perceived wrong, while Goleman sees it as failure of social restraint in the mind blind state associated with internet communication. Perhaps it is the combination of the two? In any event, failure of social restraint is evident in the flaming cow pies liberally dotting the comment landscape of some popular blogs.

7/29/07 Myths of Innovation

I see Scott Berkun's book, Myths of Innovation, is out. Here is a great footnote to the discussion Charlie and I have been holding:

How you define the problem is possibly the most important element in the success of your solution. This quote from Einstein sums up an important point in the chapter nicely: "If I had 20 days to solve a problem, I would take 19 days to define it."

from one of the reviews on Amazon

I'm inspired—Scott Berkun got that book written in great time! He's going to fill that bookshelf he set out to fill with books he's written! Now, if I could just make space for an empty shelf! My life is too crowded with work and kids. Hmmm. Either the work or the kids will just have to go. Um... maybe not.

Anyway, I'll have to take a look at Myths of Innovation.

7/30/07 DoDAF

7/30/07 Yet Another Book ... to peek  at

Ostensibly, Harwell Thrasher's Boiling the IT Frog is a book to help non-IT people get IT, but it appears to be equally oriented to helping IT people get it—business alignment, that is. It won't make my short-list of "essential" reading; indeed it is not targeted at architects. Still, I chuckled at the chapter titles and nodded at many of the secrets. Here's a taste:

Secret 16: All projects have risk. Good projects deal with it, and bad projects just hope for the best.

But I have to wonder, is secret 31 career suicide, or does the discussion of the secret in the book redeem the author?

Secret 31: The best way to communicate with an IT organization is to talk to members of the organization as if they’re from a foreign country and don’t speak English very well.

from Chapter 13: Parlez vous Anglais? Dealing with IT People, Boiling the IT Frog

Oh I know, techno-lingo can sound as inscrutable as a foreign language to the business person. I like the chapter title though. That's the essence of the secret. When holding dialog across the vernacular of different domains, we need to find common linguistic ground, the lingua franca. Or have a translator. The architect often has to play that role. How often have you heard your business people say "can you tell me what he just said?"

7/30/07 NDepend

Right in the midst of a back-to-back set of client engagements followed by 2 weeks camping and steering clear of "civilization," I got a request to link to NDepend and I'm afraid I was very remiss! Yes, I promised to link to NDepend in our Tools section on the Resources for Architects Links page and I completely forgot to do it! It's a neat tool. I really feel bad! If you're in a .NET shop, please do take a look at it! And tell Patrick Smacchia I sent you. :)

7/31/07 Chief Architect Positions at Intuit

Chris Cox posted this email to the Visual Architecting Google Group:

This is Chris Cox from Intuit and we are looking for 2 Chief Architects. One in San Diego for our Tax Suite and the other is for our Small Business Division working on one of our brand new products. Please contact me if you have any questions or recommendations. I can be reached at chris_cox at intuit.com I look forward to hearing from anyone you might recommend.

 

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.

Referencing journal entries: I figure at some point, someone, somewhere, is going to find something I've written worth linking to. I know, it's a long shot. But hey, it's a world full of different people, and if I write long enough, someone is going to stumbleUpon this Trace in the Sand and be delighted enough to want to tell someone else about it. 

So, here's how: To link to a particular entry, I bookmark and link to section titles from the sidebar, so you can copy the shortcut (from the sidebar).

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 © 2007 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: July 11, 2007
Last Modified: July 31, 2007