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 Pritchett—his
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 groups—meeting
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!
Imagine—the
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, imagine—if
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 backlash—I 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:
-
Solutions Architect, Wal-Mart Stores Inc., Bentonville, AR
-
Principal Enterprise Architect, Fair Isaac, CA, MN, GA or CO
-
Enterprise Business Architect,
KeyCorp, KeyBank National Association, Cleveland, Ohio
-
System Architect,
KeyCorp, KeyBank National Association, Cleveland, Ohio
-
Vice President and Manager, Enterprise Architecture,
KeyCorp, KeyBank National Association, Cleveland, Ohio
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 change—lowered 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
time—namely, 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 reason—we 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
-
The Power of the Tale: Using Narratives for
Organisational Success,
by Julie Allan, Gerard Fairtlough,
Barbara Heinzen, Wiley, April 10, 2002
-
The Story Factor, by
Annette Simmons, Perseus Books Group; 2Rev Ed edition,
March 22, 2006
-
The Leader's Guide to Storytelling: Mastering the Art
and Discipline of Business Narrative
by Stephen Denning, Jossey-Bass,
April 22, 2005 [Amazon upgrade to markable online book
available]
-
Beyond Bullet Points: Using Microsoft PowerPoint to
Create Presentations That Inform, Motivate, and Inspire by Cliff Atkinson,
Microsoft Press, March 2, 2005
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:
-
Confusion about what requirements and architecture
are
-
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:
-
The development and
deployment organizations don’t always have the same
interests or needs.
-
The “typical”
deployment organization is a myth. There are many.
They operate under different sets of conditions and
different business strategies.
-
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 on—lessons
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: I
welcome input, discussion and feedback on any of the topics in this
Journal, my blog, and
the Resources for Architects
website, or, for that matter, anything relevant to
architects/architecting/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: The link
to the current month's entries is always
www.ruthmalan.com/Journal/JournalCurrent.htm (but if you're linking
from a blog or website and want a permanent link, use
www.ruthmalan.com/Journal/2007/JournalJuly.htm; follow the same
pattern in future months). 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).
