back in March I said you could expect less in the way of
flowers, but it has been such a verdant Spring and the digital
camera revolution--in good part thanks to software--has opened up a
whole new way of appreciating the detail in flowers (without
breaking the bank on pro-caliber macro lenses)!
5/3/09 Hammered Truth
mentioned a phrase that struck him reading The Floating Island
to the kids a few weeks back. In the story, Ven's father told him to
speak only the "hammered
truth" and the king lighted at this and appointed Ven to bring him the
"hammered truth" from his travels around the world.
Isn't that great? There's the truth, and there's the
'hammered truth--facts that are
not varnished or hidden, but shaped straight, like steel that has
been hammered... "Tell people the hammered truth and it will ring
like steel against an anvil."'
The truth that has taken the pounding of time and experience. The
essential truth. The consultant, and the architect as consultant,
needs to find that truth when we are called on to
speak truth to power. Which is not the same as using the truth
to hammer our point home! The truth needs to be handled with
dexterity, even delicately, to ring clearly.
5/9/09 Nice Words from Around the
I don't have even a reading knowledge of Portuguese, but from
Google's translate feature I have a rough idea that Marco
Aurélio's post titled
da Ruth Malan - A Trace in the Sand is kind--thanks Marco.
It is good to see (mostly by inference) the good work you're
involved in, building the software architect community in
I do have a barely serviceable reading knowledge of Dutch,
and G.J. Timmerman has a
good summary and introduction to our "What
It Takes to be Great" paper and architect competency
framework. I do rather like "inspiring" being used as an
adjective related to our work, since I explicitly set out to
inspire --and enable, of course.
the framework we use for what we do in our workshops and in our
writing: inspire and enable. It is also what I believe
architects need to do. Even if you have formal authority, it is
more effective to motivate and enable the team to create a great
system: effort required? effort inspired. And? enabled, of
5/9/09 Recital Season
We're approaching the end of the school year, so this is school play
and recital season, and we've been kept busy with piano, ballet, and
recorder recitals, class plays, Spanish plays, and on, and on. It's
fun though, and "Weezie" Smith's recorder students (of all ages)
have a great program.
Weezie Smith is a consummate teacher--she is demanding but
she helps her students reach for the best in themselves by
inspiring and encouraging them. Their ballet teacher, Doricha
Sales, is likewise demanding and no-nonsense, but she is always
talking about the bigger context of a specific learning point,
and helping the children envision themselves as dancers,
inspiring them. And me!
Inspire and enable.
5/9/09 Ban Powerpoint?
course not. But...
McNealy famously declared
to the San Jose Mercury, 3 August 1997: "We had 12.9 gigabytes of
PowerPoint slides on our network. And I thought, 'What a huge waste
of corporate productivity'. So we banned it. And we've had three
unbelievable record-breaking fiscal quarters since. Now I would
argue that every company in the world, if it would just ban
PowerPoint, would see its earnings skyrocket. Employees would stand
around going: 'What do I do? Guess I've got to go to work'."
Powerpoint: A Pig through the Python,
Richard Hillesley, 2007
And Tufte famously headed a Wired article:
"Power corrupts. PowerPoint corrupts absolutely" -
Don Norman responded to Tufte
of Powerpoint. But the point, of course, is that when
conversation is needed, PowerPoint may not be a good tool:
creates an obstacle to an honest, shirtsleeve conversation. While
PowerPoint didn't invent one-way communication, it certainly
Lou Gerstner's remarkable turnaround of IBM from near-collapse began
with a briefing he asked for on the state of the mainframe business
that accounted for more than 90 percent of the company's profits,
which were sinking fast. Gerstner describes this critical meeting in
his book "Who Says Elephants Can't Dance" as follows:
"At the time, the standard format of any important IBM meeting was a
presentation using overhead projectors and graphics on
transparencies that IBMers called—and no one remembers why—"foils."
Nick was on his second foil when I stepped to the table and, as
politely as I could in front of his team, switched off the
projector. After a long moment of awkward silence, I simply said,
"Let's just talk about your business." I mention this episode
because it had an unintended, but terribly powerful ripple effect."'
PowerPoint: Boon or Bane?
August 01, 2007 By Abhay Padgaonka
"talking at" tendency that using PowerPoint as a prop promotes,
David Clarke also banned PowerPoint:
"As CIO for a global company a
few years back, I actually banned PowerPoint presentations in my
team for a while. ... The problem was that our attention span had
become so limited that our level of conversation had degenerated to
this bullet point way of talking and thinking. We were presenting to
each other, not talking with each other. We didn’t know how to
engage people in other ways, so we took the few minutes we got and
gave them the Reader’s Digest version of the idea we wanted to
Banning PowerPoint Reveals Flawed Communication,
By David S. Clarke, November 15, 2001
5/11/09: PowerPoint is not the issue, really. It is comes up,
because it is the de facto tool used to prepare presentations, and
the issue is using one-way presentation when conversation and
collaboration are needed. It's not just the "bullet points,"
it is the style of having the "podium" and managing attention to a
preset agenda dictated by the slideset. In short, it turns meetings
into lectures. Again, this is not Powerpoint, per se, but it is the
mode we just fall into where we use a tool (Powerpoint, or our UML/round-trip
engineering tool) and let that drive attention to center stage to
the person with the mouse/clicker, when "people and interactions"
need to be front and center.
When we want to communicate that we are fluid about our
ideas--yes, we've done homework, but we're still in an expansive
(divergent in the sense of gathering ideas), input-seeking
mode--then drawing and capturing brainstorm ideas on a whiteboard or
paper is a great medium. Yes, the facilitator still has influence
over the flow of the agenda, but we don't get the same domination of
the attention space as one typically gets with a prepared Powerpoint
(or other) presentation. The message that is communicated is "we're
open to input and open to shaping the flow of conversation around
the audience concerns, goals and input."
A few points about
if the meeting room
walls are short on white-board space, be prepared with extra
sheets of paper or flip chart pads and painter's tape, and make
sure that all work done in the meeting is visible at
all times by taping up the paper as each sheet is completed.
That way, you don't have to erase work to make room for more
have a digital camera
at hand and take pictures of the work--even if there is the
intent to transcribe from whiteboard and/or paper to electronic
form, still take digital pictures so you have a meeting record
to refer back to.
if you have designs,
facts and figures, etc. to share as a backup to discussion, a
(draft) white paper may be a good vehicle.
Realizing that I'm on a "visual kick,"
sent me this link:
may help memory recall.
We have long known the value of keeping the hands busy with
something that doesn't require mental focus, to free the mind to
pay attention. That is why we use Koosh balls in workshops! I
suppose we could just ask people to doodle! Still, the Koosh
balls also help people when they're presenting their team's work
to the larger group. Keeping their hands busy with the ball,
seems to allow even shy people to be less self-conscious. It is
funny, but when I tell people what the Koosh are for, fewer seem
to fiddle with theirs. You'd think it would be the other way
round! Watching how people deal with the tag, I've made it the
first exercise of the workshop to remove it. It gets people
fiddling, and gives me the opportunity to quip that it is
emblematic of the evolution of man--some brute force it, some
use a tool, and some apply conceptual modeling and "reverse
engineer" the loop.
I get an immediate hit on personality types! (Uh, not that I'd
want to imply that I map personality types onto an evolutionary
As for my "visual kick"--I am, actually, actively pulling
together material on the role visualization plays in
architecture, so please join Daniel in sending me links and
ideas, anecdotes/experiences, whatever. I'm working on a
presentation for a CAEAP
event. My working title for the presentation is "PICTURE IT" but
I'm also playing with 'Drawing People In" which has a double
entendre that I like, given my message.
6/2/09: There's also an article on
doodling on npr (March 12, 2009).
6/5/09: Here's an article on
Powerpoint Design and visual thinking.
Every year, Bloomington has an Early Music Festival, and
Weezie Smith is active in the program. At the recorder recital
(where the kids and adults played a number of Renaissance
pieces), she recommended
Orchesography by Thoinot Arbeau. Written in 1587, it
presents music and dances of the period. It has an interesting
annotation for drum beats on the music score and an annotation
for the dance steps, as well pictures of dancers showing the
costumes and footwork. I remember Grady Booch mentioning a
visual language for dance (labanotation)
in one of his blog entries several years ago. Anyway, it fits my
theme of visualizing--in this case using a visual language to
create and record something that is inherently visual, but still
hard to capture on paper without a language that is at least
somewhat standardized to allow consistent interpretation. Last
year I jotted some notes and thoughts on a similar topic--a
language for origami.
There are those who argue we have a language for expressing
software systems, and it is the code, so we shouldn't duplicate the
code with models that will just get out of sync as the code is
adapted and evolved. Of course, architecture models aren't meant to
be models of the code, but models of the architecturally significant
structures (including dynamic models of the structures in action,
under load, etc.). Yes, these will be built with code, but there is
an important distinction between the architectural elements
(services, components, mechanisms, ...) and the code that manifests
these elements. For one thing, architectural elements are (largely)
implementation language neutral (or at least, can be constructed
using various languages within a genre). For another, they are
important, in their own right, elements of design attention during
initial design and during ongoing evolution of the system. They
require thought, experimentation, testing/evaluation on paper and
testing as constructed elements. That is, they allow for an
important separation of concerns that supports designing systems
that are "at once simple and complex" and which can be understood
and built by teams of people working together as if of one mind to
create a coherent system.
I read a
blog post by Nick Malik that argues that agile architectures
need about 10 pages of diagrams and nearly no supporting text. There
are contexts in which that advice is good, but out of context I
think the advice can be quite harmful. Models without supporting
text need conversations to fill in for the missing text. Now you
know that I absolutely value those conversations
(and have deep misgivings about the setup in many IT shops where
architects "parachute in" for the "architecture stage" and get
pulled out before construction begins, to go parachute in on the
next architecture assignment). But the text is still important! It
takes considered attention to write up the rationale for decisions
inherent in the models, and both the rationale and the attention are
vital. So, orchestration is important here. There is a pulsing that
needs to happen in concept formulation and maturation, as well as
during construction--during the expansive idea-gathering phases,
informal sketches and conversations with explanations and rationale
jotted down by hand are quick and good for keeping the team fluid
and the concepts malleable. During the convergent decision making
phase, we extract the learning and make decisions and we need to be
disciplined (but not exhaustive and exhausting) about recording the
decisions and their rationale/justification/explanation and
implications. Otherwise the lack of discipline mounts, until the
task is just too big. These decisions become stakes in the
ground--and it is easier to see when a stake needs to be moved than
when it is just a mental marker someone has in his/her head that
he/she may or may not remember to share with all affected.
This doesn't mean creating a 3lb "brick" to toss over the
waterfall at developers! But minimalist is not nothing, and it is
not just a few diagrams open to varied interpretations and reliant
on repeated live explanation. The live explanations are important.
So are architecture documents that are vivid with pictures and
considered experience and rationale for the decisions they record
and motivate. Vivid doesn't equate with long. And architecture
documents aren't synonymous with waterfall.
It is important in some contexts to recognize that for
portfolio/investment and product and project management purposes we
need points at which the system concept, then architectural design,
then early functional deliveries, are mature enough to make bigger
project-related decisions. But this doesn't mean we dispense with
concurrent development and stakeholder participation, iteration and
active learning about requirements and the structure that will best
support them. We set out to fail fast and cheap, so that when we
make our major investments in construction, they start out in a
direction that makes sense for the market. Yes, we'll continue to
learn and refine and evolve the requirements and architecture, but
we're pointed in a high-payoff direction.
Taking HelpMatch as an example, one workshop team worked with an
operating model that included a physical warehouse/distribution
center for donations. During ideation, you want to be able to assess
options like that against other alternatives "on paper" without
going to the expense of a physical trial! Other teams designed a
system that matches offers and requests for donations. One team
assumed that donors would look at requests, and self-select which
requests to fill. These are not just operating model decisions,
because there are substantial costs, challenges and risks inherent
in the system that supports the different operating model
alternatives, and the operating model is best considered with the
these costs and challenges in mind. This means that even though the
system concept stage-gate can still be a useful management
construct, the activities that lead up to it include architecture
work as well as market research and operating model formulation. But
the architecture work doesn't have to be rigorous and can drop into
logical and physical design views only as the architect needs to, to
explore make-or-break challenges and risks.
In short, we can map a highly iterative, agile process onto a
stage-gate process, but we need to bear in mind that the stages
should not be taken to imply functional islands of
activity (marketing/requirements | architecture/design |
construction | system test). Instead, the intent of the stages
(set a target, refine and elaborate the target, build towards
and refine, and possibly adjust, the target) is best met with an
agile, concurrent development process and role design. For small
teams and relatively simple systems, the process and role design
that has been tagged "agile" is most effective. For more complex
systems (for example, products with embedded software, or very
large software systems, etc), more work may need to be done to
enable several agile teams to work in parallel--as described in
Getting Past "But."
5/12/09 Testing on Paper
The other day an image of a dam wall design came unsummoned to
mind, and it struck me how important it is in that case to "test"
the design on paper.
Yes, it is also thought about, communicated,
and tested and improved with 3-D physical models, and computational
models--but also just sketches. Of course I knew, but hadn't
explicitly formed the thought in exactly these terms--that one of
the things that designs do is enable us to test the design on paper.
Oh yes, this is not the "be all and end all" of tests! But we are
intelligent beings and we can use our imagination and experience to
run thought experiments (this
Einstein reference I have
long used, as you well know). When we see an architectural
drawing of a home we're having built, we can imagine doing the
things we do in the spaces of the design. When we're designing a
software system, we can use storyboards, yes, and also play out the
collaboration among the architectural elements and weigh
alternatives. And we can use these models to structure further
analysis, for example creating stochastic models to better
understand the scalability of our system.
is all obvious, but it is one of those cases where the blindingly
obvious blinds--all the "agilists" who dismiss models are dismissing
this feature. The defects that carry the highest cost, are those
that are the most strategic--relating to missed markets and major
structural flaws. Every one of these that we eliminate cheaply
through quick and dirty paper testing (and quick and dirty
prototyping) is a big win, because discovering them when even a
partially built system is already in place can be outrageously
Models help us think, and models help us test our ideas
cheaply, on paper even. And they create that shared group
thought-space where we can collaborate on the design, and also have
others help test our designs. This is what we mean with early
validation of course--that has been part of VAP since its inception.
But I think it makes a difference to say "test on paper". It is
quick, it is crude. So to the extent that it allows us to find flaws
and opportunities, and evaluate alternatives, it is cheap. Far
cheaper than building even a slice of functionality--though it
typically takes more than just a slice or two to learn the key
lessons of system fit to context and design fit to purpose. The
trouble with BDUF is that it sought to be right (with a stage-gate
review but scant if any attention to conscious design
stress-testing) and complete with the result that design documents
were big and it took so long to do that the context was liable to
shift, and it gave a bad name to doing any DUF. We don't want
to go to exquisite
detail on models that are just there to support thought experiments!
Nor even to document the architecture decisions as they mature. Just
enough. Not more. But also not less.
architect has to use judgment, and one of the most crucial areas of
applying judgment is in this area of what is enough, but also being
careful to stay fluid and fleet and not rushing to cement initial
choices in system concept and structural design. We have to put
aside that frenetic code-is-all-that-counts schedule focus for a
while, and be creative and investigative--explore possibility,
opportunity, challenge and risk. To not do this, is to become locked
in to our first ideas, and they are dangerous because they are the
old ideas, the top of our mind ideas--in short, they are everyone's
ideas because they are the easy ideas! Not exactly the ideas to
differentiate upon! We have to, in Think Better terms,
release the flood of ideas, let the tired old foregone conclusion
set of ideas tap out, so we can get to the new, fresh ideas that
will see us through the next epoch for the system we're
5/21/09: "Testing on paper" is much the same as "experiment on
paper" and I've covered that notion in at least one
earlier post (that, of course, is an understatement). It is
useful, I think, to have both ideas in our "back pocket," because
test speaks to some in our audience (perhaps those who are risk
sensitive) and experiment speaks to others. Anyway, since I've been
emphasizing the notion of thought experiments and crediting
Einstein, I thought I should get better informed. According to the
Psychology Wiki, credit should go to Hans Christian Orsted, who
used the German equivalent of the term in 1820.
5/30/09: This may help make a case for JEDUF:
Not so fast with that marshmellow...
5/12/09 Drive Convergence, or Lead?
Driver-driver types may prefer no-nonsense "drive convergence"
wording--yes, "Drive in business terms is really a word for making
something happen"--but it has a very dominance
Collaborative types will find "drive" paired with "convergence"
uncomfortable: People aren't cattle. We don't align people the way
we align wheels on a car. And so forth. This is why "change
management" was an unfortunate term--you don't manage change, or
drive it; you lead change. (Outside consultants can't lead change in
a client organization; the notion of change management consultants
was flawed. Coaches they may be.)
We had the "with teeth" principle because we believe the
architect needs to be empowered/given authority. But the architect
who leads (a "from the front" image) rather than drives (a "from
behind" image) recognizes that this is about the creation of systems
in highly collaborative contexts.
Many architects have authority because they are viewed as
authorities (meaning competent), not because they have formal power
in an authoritarian, hierarchical sense... it is a "in the person"
leadership quality rather than a "in the organizational hierarchy"
quality. Of course, it is good if the formal organization supports
rather than undermines the informal flow of authority, but the
informal is powerfully effective.
Sara asked me to "draw
something, not just a stick figure." She wanted to see if I could
still draw--I'm stung! But not because I think I can draw... No, I'm
stung on Archman's behalf. Archman isn't (just) a stick figure!
He (and she) is a stick character. There's a difference. (I think.
Tim Armstrong of Google
more primitive sketches than I do...
I have noted that Ryan draws the most amazingly accurate
aircraft, fish, whatever, but all his people (even on the same
an elaborately detailed machine or fish) are stick
figures. Sara draws people with incredible accuracy down to the
fingers and toes, and Ryan and I draw "stick figures." I wonder what
that means? Grin.
Modularity as a strategy for managing
complexity is discussed in:
Vijay Narayanan let me know that his article on
services was published in SOA Magazine. Thanks for the pointer
Vijay. You're paying attention to an important set of concerns in
Adrian Grigoriu also let me know that the 3rd edition of his book
on Enterprise Architecture is now in stores.
If you would like to suggest papers and books for inclusion on
the Bredemeyer site, please do be sure to let me know, because it
might otherwise take me a while to stumble upon them.
5/15/09 On My List
Looking over Grady Booch's architecture and related books list, I
realize I need to catch up on these:
- Ferguson, E.
Engineering and the Mind's Eye. Cambridge,
Massachusetts: MIT Press, 1994.
- Petroski, H.
Invention by Design: How Engineers Get From Thought to Thing.
Boston, Massachusetts: Harvard University Press, 1996.
- Petroski, H.
Small Things Considered. New York, New York: Alfred A.
- Petroski, H.
The Evolution of Useful Things. New York, New York:
Vintage Books, 1992.
- Sclater, N. and Chironis, N.
Mechanism and Mechanical Devices Sourcebook. New York,
New York: McGraw Hill, 2001.
- Pahl, G. and Beitz, W.
Engineering Design. London, England: Springer-Verlag,
- Hubert, R.
Convergent Architecture. Hoboken, New York: Wiley,
- Pastor, O. and Molina, Juan.
Model-Driven Architecture in Practice, Springer-Verlag,
- Sessions, R.
Simple Architectures for Complex Enterprises. Redmond,
Washington: Microsoft Press, 2008.
- Spinellis, D. and Gousios, G.
Sebastopl, California: O'Reilly Media, 2009.
Taylor, R., Medvidovic, N., and Dashofy, E.
Software Architecture: Foundations, Theory, and Practice. Wiley,
I found that our
bibliography was seriously out-of-sync with our library, so I've
put some cycles into updating that and still have more to do; way
5/18/09 Hemingway on
"If a writer knows enough about
what he is writing about, he may omit things that he knows. The
dignity of movement of an iceberg is due to only one ninth of it
being above water." -- Ernest Hemingway, Death in the Afternoon,
A Sea of Change, a biography of Hemingway, for his most
recent book report. Given what Ryan learned about Hemingway's
"iceberg principle" from the biography, he wrote:
"In The Old Man and the Sea,
Hemingway uses a technique of writing in which only the necessary
information is provided. He called it illustrating the iceberg." --
Ryan Bredemeyer, 5th Grade Book report, May 2009
"illustrating the iceberg" a great metaphor for (visual) software
architecture? Talk about catchy names for principles!
was clear that one shouldn't use this as a technique to mask what is
not known, for that disingenuousness will be apparent; what is known
and can be assumed to be known, can be left unsaid or sparingly said
as we illustrate just the portion of the iceberg that we want to
make visible. Minimalism and deferring decisions is an intentional
strategy, but the intent is not to deceive. We need to know enough
about the iceberg that we can illustrate the iceberg and have it
Researchers in the field of organization theory (organizational
sociology including evolutionary theory, and organizational behavior
including organizational learning) have looked at organizations as
bundles of routines and capabilities (or competencies, in earlier
work). Interestingly, organization theorists are looking at
capabilities and architecture:
"The overarching objective
would be to see how the architecture of the organization, including
its divisional structure, transfer pricing, incentive policies, and
socialization process relates to the architecture of its
capabilities, in terms of both productive capabilities (how well it
works a whole) and dynamic capabilities (how effectively it can
Michael G. Jacobides, "The
architecture and design of organizational capabilities,"
Industrial and Corporate Change, Volume 15, Number 1, pp.
"Organizations and their
design, then, can be seen as different “shots,” different “bets” as
for how to deconstruct complex tasks which, interdependent as they
might be, cannot ever be carried out by a fully integral, entirely
interdependent organization, due to the cognitive strain this would
impose (Dosi and Grazzi)."
Michael G. Jacobides, "The
architecture and design of organizational capabilities"
referring to Dosi and Grazzi,
Technologies as problem-solving procedures and technologies as
input–output relations: some perspectives on the theory of
production, Industrial and Corporate Change, Volume
15, Number 1
5/20/09 Updates to
Resources for Architects Books Lists
I updated the
Visualization, Problem Solving and Creativity page on our
Resources for Software Architects website--though there again I
would need to do more if I wanted to sync up the page with what we
have in our library--or even with what I like best of what we have
in our library. Other Tufte books, at least one De Bono Mindmapping
book, and Maeda's Simplicity book all come to mind as books I
would recommend out of the larger set I've read.
5/20/09 Ok, Since No-one Else...
Did you notice this
line in last month's journal:
Creativity needs a palette of
more colors than black and white!
Isn't that inspired? You know, black and white--the color of
code, of bulleted lists, ...
5/21/09 Architecture Journal--Call
for SOA Papers
Microsoft's Architecture Journal is
calling for articles on:
SOA practices. Which ones
determine the success-or failure-of a project?
SOA governance. Running,
monitoring, versioning: How better to serve services?
To ESB or not to ESB. Angel
or demon? When to consider it a fundamental piece? What about it
should you get rid of?
From object to services.
Considerations to guarantee separation of concerns after
Enhanced SOA. How
alternative, complementary approaches such as Event-Driven
Architecture (EDA), REST protocols, service virtualization, and
others are helping SOA traverse the last mile of integration.
SOA and The Cloud. What
SaaS, S+S, and related emerging delivery models have to offer to
an in-house SOA investment.
5/21/09 Illustrating the
Grady Booch has been quiet of late, so I suppose
the quote in his last blog post speaks volumes in an "illustrating
the iceberg" kind of way:
mind that knows itself also knows the body, which houses it, is
decaying. It knows the end will come. And a mind forced to
contemplate such emptiness is a force of rare creativity."
Beckett, Genesis, 2009
Randy Pausch, facing a ticking clock with not much battery life
left, told himself: "Today is not
the day." And with his Tigger-buoyant energy he made each day
count, for himself, for his family and for all of us who received
his legacy. When it is all done, on this project, on this step
of our career, in this life, what will stand as our legacy? Uh... I
have a book to write! Ciao!
Oh, speaking of Beckett, but a more
famous one--Dana saw Waiting for Godot at the Theater Royal
in London last week. And he saw Billy Elliott (the musical)!
You don't even have to see me to know that I'm green with envy!
5/21/09 API Design
pointed me to an article in the latest Communications of the ACM
that is a worthwhile read: "API Design Matters," by Michi Henning
5/23/09 Illustrating the
Iceberg (from another angle)
Regret minimization, short tenure on this planet, all of these
things are sobering reminders that if we want to do something big,
something worthwhile, we better get on and do it. Outside in the
peaceful dark last night, looking at the stars, I realized that my
wellspring of motivation is not that ... uh... schedule pressure. It
is joy. And I am so grateful for joy; for the joy of man's aspiring,
creating, being in this world.
There is so much pain; evil and cancer that takes lives in
hideous ways. Even when we live with awful realities remote to us,
time runs its determined course through us. Like sea-sand through
our fingers, it is futile to hold onto; besides there is pleasure in
the pouring through. We human beings find joy in expansive
awe-struck seeking is our grace.
The sword of Damocles notwithstanding.
5/25/09 Visualizing Panic!
I'm still on my visualization kick, trying to think about how to
do my presentation at the CAEAP event conveying the power of drawing
people in with pictures--by drawing people in with pictures... but I
only have 20 minutes and some 30-40 people so not my usual cozy
format where we can all draw around a sheet of paper. I watched Dan
of the Napkin" talk that he gave at Google last year. So Dan's
all about pictures and he draws live right? No. Well, he highlights
live, but he has his hand-drawn images all Powerpointed up in
advance. That doesn't feel altogether aligned to me, but I'm
sensitive to the logistical considerations...
Dan Roam does make a great point along the lines of those that
Sir Ken makes: ask a class of kids in kindergarten if they can
draw, and all hands shoot up. Ask them if they can read and write,
and only a few hands are raised. Then ask the same question of 16
year olds, and you get the reverse. We start out knowing how to
draw, or at least being unabashed about our ability to visualize and
render images, and it is educated out of us. So Dan has developed a
strategy of getting people to draw a me="not
very smiley" face right off the bat, to get past the blank
5/26/09: Enterprise architecture arose because the "divide and
conquer" approach was leaving a bloody* mess... Alternatively put, a
bunch of people have been feeling the proverbial enterprise
elephant in the dark. Business people. IT people. Marketing. HR.
Functional silos. Business unit silos. A way of seeing the
whole elephant was needed.
And another bunch of people have been feeling the visualization
elephant--engineering designs (from informal sketches to formal
notations in electronics, software, etc.), process mapping, decision
charts, graphical facilitation, etc. Those coming at the elephant
from the business side posit a set of visualizations, and those from
the engineering side another. Again, a way of seeing the whole
elephant is needed.
In just 20 minutes, I want to help people see the elephant. The
So they can draw the elephant.
Oh dear. I do seem to have a thing about elephants!
Well, I'm not the only one. A group we worked with (somewhat
tangentially) calls their development process "the big elephant"
because that is the shape their process diagram takes. They could
draw an elephant, but realized we helped draw the elephant
(rather than being relegated to trying to shove it from behind).
* Uh, sorry; that's rather too
Monty Python, isn't it... I spent the past two days chaperoning fishing camp with
three eleven year old boys. I told my son I'd rather he didn't spend
quite so much time with his head in the toilet (figuratively) on one
of the rare days I take off... Now here I am, using bawdy double
entendre. I'm just so susceptible at this age. :-)
5/25/09 How Does a Restauranteur Know So Much?
5/27/09 Only You and I
It occurred to me that when I talked
about removing the lid, I did so in purely self-serving
terms--I needed my memory crutch, and I expressed no gratitude or
concern for everyone who'd taken to reading my journal as their
soporific fix. The fact that I generally journal at night (unless
I'm trying to catch a thought and pin it down), might have impacted
this skew in my site visit stats. But more likely it was the
soporific thing. So it was rather cavalier of me to discount those
for whom my journal had become a habit.
Please allow me to explain. I hope that people get value out of
my writing. At the same time, though, I'm sort of incredulous that
anyone would actually want to read this journal. So it is not that I
discounted you, but rather that I discount myself... Moreover, I
didn't realize that this would impact quite so many people, but the
fall-off in unique visitors from late March to May was staggering. I
just made the (entirely rational) assumption that there was my inner
circle of architect friends who kindly show me undue forbearance,
and a bunch of random others who were just one-stop-hopping, looking
to see if this Ruth Malan person on the
Bredemeyer site was someone
to not take
a class from, or something like that.
So, I do appreciate and thank everyone who reads here, and
especially those who return here. Your hope that I might say
something useful and interesting at some point, demonstrates a
remarkable capacity for hope--that will stand you in good stead as
an architect. Well, there it is--that useful and interesting thing
you were looking for. Hope. For how can architects lead if they
don't have an unstoppable belief in people, and their capacity to
strive for, and sometimes reach, pinnacles of excellence?
And I do strive. Ad nauseam! Ciao!
5/27/09 Hand-drawn--Good Enough for
Well, well... I'm looking for a replacement scanner, and stumbled
scan2 page. Pretty cool! I
just hope their system vision looked like that! Yours does, right?
My scanner lacks the "adjust the color/contrast/brightness so the
background is light/white and free of artifacts" feature, so I've
reverted to scanning in black and white, but it would be nice to be
able to scan color sketches without getting paper grain noise and
Anybody using LiveScribe?
Do you like it?
I've tried a pen mouse and tablet PC and in both cases--nice
idea, not there yet. Perhaps I happened on the wrong ones, so if
you're using and liking either, please let me know. My drawing
skills and handwriting are weak enough on paper, that I can't afford
any deterioration through the drawing medium!
Graphical recording/facilitation blogs:
Nancy White (she casts herself as a graphical recorder, but
she does also use graphic templates to facilitate sometimes)
I like this definition of collaboration that I stumbled on (by
way of Nancy White):
'To be collaborative means that
you embrace a certain way of
life and work ... an openness to
the ideas of oth- er people, and
in particular to how their ideas
and perspectives may mold,
change and transform your ideas.
The heart of collaboration is
openness to the ideas to others,
and a stated and acted upon
willingness to explore those
ideas, rather than assuming that
everything you think is right
and correct from the get-go. To
be collaborative then, is in
essence a human process, that
plays out over whatever modality
of interaction you use with
other people, be that
face-to-face, email, a wiki or
any other "collaborative
Thoughts on "Collaboration",
August 15, 2008
Reinventing Archman? Three boxes and database feet...
more like conceptual architecture... hmmm...
McCloud did the
Chrome Comic. I don't think I noticed that when I first
encountered it, but I should have known! I agree with the
comment: "a masterpiece of
software documentation." Scott points to an
XKCD comic strip saying:
"Despite the crazed fantasy
storyline, Tym is mapping the sort of intersecting, branching, and
colliding paths that people in real life take all the time, but that
only comics can make visible."
my mind's eye, I'm forming a picture of this CAEAP presentation.
Which reminds me, I'm enjoying Eugene Ferguson's
Engineering and the Mind's Eye--thanks Grady. Well, I came
by the recommendation indirectly, by which I mean it is on Grady
Booch's books page--it's behind his login barrier, but it is well
worth the entry effort to catch up on his architecture gallery,
patterns catalog, and resource/references pages.
to Scott, I spent some time with
Bat for Lashes tonight;
they have a pleasant musky sound. I'll have to follow up on more of
the recommendations in Scott's post.)
5/28/09 The Meaning of Life
(Dana is to be credited for the title of this piece.) There is a
Machiavellian streak in many organizations and governments, and I
don't understand why too many of our leaders have embraced meaning
in the sense of being mean and diminishing people, rather than
meaning in the sense of creating meaning, making life meaningful and
uplifting. To understand, I might need to go back to two of the most
influential books on executive and leadership reading lists:
But if one goes there, then another favored exec read pops onto
5/28/09 Handwritten Thank You
I mentioned Weezie Smith and the
inspiring example she sets, and I've mentioned Randy Pausch's
handwritten thank you notes. Well, Sara drew a portrait of
Weezie as a gift to thank her at the recital, but then she got
frightfully shy and folded it up into a palm-sized wad before giving
it to her. Weezie framed the portrait and wrote Sara a thank
you note. Isn't that wonderful--seeing the shyness and responding so
thoughtfully and kindly to it. Some people lead "the good life," and
some people lead a good life. As for me, I just struggle with
leading a life--with glimpses of what it would be like to lead a
good life from paragons I encounter. In truth, I guess they struggle
too, but are just more grace-full than I!
Last month I watched
Brown (of IDEO) talk about
creativity and play (video on TED),
and I wrote:
Tim makes the point
that "thinking with your hands," for example by building low
resolution prototypes (e.g., using masking tape and children's
clay), stimulates creativity. It helps to quickly get your thinking
into the real world so you can test ideas much more quickly with
users. We tend to think that because code is so malleable, and
because we do have very productive prototyping languages, it is the
best route to these early experiments. It is a good one! But
therein lies the danger. We tend to overlook other "hacks"--a cereal
box or storyboard, role play, pictures, brainstorm lists...
Creativity needs a palette of more colors than black and white!
I came back to that, because I was thinking about some of the
"tools" on Dan Roam's visual thinking "swiss army knife"--in
particular, "eyes, mind's eye, and hand-eye co-ordination."
The last seems a bit clumsily named; well, for my purposes, at any
rate. Which is to say, I think that hands, or problem solving by
building with our hands, is a critical creativity/innovation tool,
and it does give us visual feedback on the tack we're taking in our
5/29/09: This one has some
(meaning it works as emphasis in his dialog)":
Rives Def Jam.
It is astonishing! It makes me think we should teach children
sign-language from preschool--to speak with the body that way, to be
so expressive, is amazing. Of course, Rives is a performance artist,
but I have to think the rest of us could be better communicators if
we knew some of what he knows. It is often said that when we lose a
sense, other senses intensify to compensate for those we don't have,
but maybe the converse is also true--we don't develop our capacity
for kinesthetic sense fully enough because we rely on our " five
senses" and more traditional education-system-buoyed sense-making.
Researchers and leading educators have been directing our
attention to opening up the learning box to visual learning and
kinesthetic learning styles, allowing that some learners do better
with those than verbal learning. Yet it seems to me that we need to
develop these different styles in all; yes, some will be more peaked
in one style than another, but:
"a teaching strategy based on a
‘programmed learning sequence’ and designed to favor visually- and
tactilely-oriented students increased attainment for all students in
the experimental group." -- wikipedia,
Now JPL and NASA and Boeing,
before they will hire a research and development problem solver,
even if they are summa cum laude from Harvard or Cal Tech, if they
haven't fixed cars, haven't done stuff with their hands early in
life, played with their hands, they can't problem solve as well.
Stuart Brown says
play is more than fun (TED), May 2008
It occurs to me that it's not just in learning, but in creating,
that we need to utilize these other modes of exploring ideas and
solving problems. And I hypothesize that we can benefit from, and
strengthen, these other problem solving styles by practicing them.
And have more fun!
Our brains are very effectively encapsulated. Well, Twitter is
breaking some of that down, and people's thoughts are leaking out
pretty much as they are formed... Sorry, couldn't resist leaking
that thought... Still, we need to speak, write, draw, use body
language, build, to get our thoughts out of our heads so others can
be influenced by them, understand them, interact with them, enhance
or challenge them. Duh! Yes. But how often are we taken by surprise
because we thought we got something out of our heads, but it hasn't
influenced anyone else's thinking? Communication and collaboration
are enriched by using multiple channels or styles--helping people to
see what we mean through visualizations and tactile models, not just
words. And inviting them to co-create the visualizations and tactile
models, so they get actively involved in creating a shared group
thought-space--on paper, in clay, or a role-play, etc.
Now I need to go oversee the
disassembly of the defunct lawnmower, just in case Ryan or Sara
ever want to work at JPL/NASA/Boeing...
5/31/09 Visualizing Data
Some examples of creative data visualization:
"The eye can process
information in the ratio of 12:3 times faster than the ear." --
structured visual thinking