Well, there generally seems to be a sense that we're ☼well
rid of 2010♫. I hope that 2011 is enriching and
rewarding in every way. Make your systems great so you do your part to spread
technology optimism! We have another round of technology-driven economic
resurgence due. Overdue!,
said to Chuang Tzu:
“All your teaching is centered on what has no use.”
Chuang Tzu replied:
“If you have no appreciation for what has no use
You cannot begin to talk about what can be used.
The earth for example, is
broad and vast
But of all this expanse a man uses only a few inches
Upon which he happens to be standing.
Now suppose you suddenly take
all that he is not actually using
So that, all around his feet a gulf
Yawns, and he stands in the Void
with nowhere solid except right under each foot:
How long will he be able to use what he is using?”
said: “It would cease to serve any purpose.”
The absolute necessity
Of what has 'no use.'”
The Way of Chuang Tzu, translation
by Thomas Merton, 1965
A software architect is generally a software engineer or computer scientist
by training and by experience, but an architect is more than an engineer. The
architect creates that crucible for engineers to do their work thinking they did
it all, each themselves, and yet it coheres within a system that has integrity.
Hence the architect, perhaps, has to step
beyond the circles of past comfort. My journal has the distinction of being
truly useless and well beyond the comfort zone of all but the most curious and
playful of awe-struck seekers. Reading here is like, well, a
tolerance for ambiguity workout. In short,
if this cap fits...
don't read another word.
Imagination and goodwill being required to get the absolute necessity of
what has no use.
Ah but, given that you're fresh with resolve to work that organ that consumes
"respectable" calories, why, December
had its share of useless posts. November
too. And if you really start to feel the necessity of what has no use, well,
I've been working on a
Journal Map, so you can
navigate your way around this tumultuous landscape of words welled in the wonder
of exploring our field.
Still Here? Wow! I'm impressed. Perhaps you'll make it into the small and
Now, to be clear, this journal
is first and foremost for me. I am my own harshest critic, and I
don't wish to be challenged from that rank. And then this journal is
for a small and very select set of architects who are
extraordinarily smart, who have an intelligent sense of humor that
catches the many layers of satire, irony and wit that permeate my
writing, and who are so comfortable with their own rare and
outstanding qualities that they can stomach my occasional indulgence
in self-congratulation. Ok, quickie quiz: just what part of this is
satire and irony and what part wit? --
We'll have dreams that will flare realities and we'll turn our back and
forget them, and they'll forget about us and we'll pass the genesis of the
dreaming to our offspring.
-- Daniel Stroe,
personal email, 1/1/11
that will flare realities" exquisite? And isn't the
wash of time, the sediment of dreams reached for and sometimes attained,
yet always ultimately broken, so depressing? Daniel ends with the
Why should we dream
Because our dreams are our affirmation of our individuality and reality.
"Cogito ergo sum."
And I dream, therefore I become. Dreams are what make us, in
words, "a verb" -- an intentional and
vibrant verb. Our dreams are essential to making a distinctive mark on this
planet, however brief. They give us that welling of rebellion, the passion
to resist the damping damning dust of indifference -- to our own self!
January. We stand ever at the portal to the future, but the turn of the
year reminds us to take stock just enough of the past to inform and energize
our future. To reassert our dreams, the invention of our self, and our
resolution to make a difference, refocusing on the important to flare and
forge the realities that have their genesis in our dreams. And to feel an
sense of urgency with the quickening rush of
(for perspective, this is
PF in 1972 doing
compelling dream and real urgency. A fine-tuned aesthetic sensibility
ensuring integrity, while the urgency cuts away the fluff. Not the fun! Just
the extraneous, unnecessary turf tzaring with all its circling and dominance
antics. The vision aligning everyone, the urgency creating focus on the
critical. The result? Enough to set me back on my heels to howl at the moon
for dreams lost in mediocre meandering, death-pale spirits that haunt our
schools and work-worlds rasping and sanding down aspirations into conformity
with an un-ambitious norm. A man-child showing us what can be done with a
life, while we shuffle dust, filling days.
All that reaching,
striving, yearning to leave an imprint on this world that is coldly
indifferent to our desire to stay in it, summed
I Can Dream
-- a kid singing of the taste of life
even as death rose in his mouth and throat.
that post in celebration of Killian Mansfield. It has echoes of
another post, written in memoriam and gratitude.
People have a tremendous impact on us. We think we are so distinctly
ourselves, and yet there is such a
parade of minds
whose thinking (and testing, proving, building in the world) gets woven into
us in ways we don't even recognize, could often not trace.
Yesterday Dana printed off the
"issue" of my journal (so he can read it away from the anchoring of a
screen) and goodness, it was 35 pages long! Was. Subsequent to that, I added
back in entries so that the archive version was more complete. I also added
entries back in to
November. I once told someone not to follow my journal because he has to
have time in the day to think his own thoughts. (He took me at my word!
I guess I don't need to tell my husband that, because he only plans
to read my journal. No, just kidding. He's my most loyal and kind reader.
For example, I told him he can't detach from the screen 'cos all the good
stuff's in the links, and get this -- he said "nah-ah."
He tells me my eyes are more blue in the most delightful way. (Seriously!)
No, no, not blue, but more blue. If you didn't pay attention in December you
won't get that, but never you mind. It was good. Great even. But you have
great thoughts to think too, and great systems to design and help build.
At any rate, I really write a lot when I'm avoiding writing. I mean, when
I'm incubating the next pieces of work that will help our field know itself,
seeing what needs to be done in the creation of sustainable systems.
Sustainable in every sense. Yes, the
refrain if you please: sustainable in every sense of the word from
technically to economically and environmentally to morally and personally.
What? Look, I framed the audience for this journal and so clearly if
you're still here you are one so
comfortable with [your] own rare and outstanding qualities that [you] can
stomach my [exceedingly] occasional indulgence in self-congratulation
are you not? No? Look, that entry was specifically designed to fend off all
but those with the most acute appreciation for my ... brand of useless
Phew. Ok, word to the wise -- we call this an invisibility cloak. Also
known as a veil of words. So donned, we can proceed to the good stuff in the
remainder of January's post. We hope!!
I know, I should put more of the time I sink into this journal that so
few people read and none recommend into getting the Visual
Architecting book finished already. I should. But I also feel that I'm
working this new medium of expression to an extent few others do ...you
groan in agreement, thinking extent=expanse, vast expanse, while I think it
is a form that can be more vibrant, more pulsing with life and
multi-dimensionality than any book. The very surprising twists and turns,
the soaring heights, the plummeting to plumb depths made more comfortable
with an ever present twist of humor. And gosh gee, it's free! Well, there's
the small matter of the cost of time, yours and mine. But you know, how does
one assess the value of what is useless? No, we're not going to put my
eBay♫ to see. Garr!
1/3/10: So, you see, it is not that I do not pay attention to and serve
my audience, much as one might conclude that I pay no due respect to the
value of the time of those who drop by here, nor the desire for the
actionable grist with not so very much of this chaff. This is an
exploration, not a distillation. This is a wild landscape, not a neatly
tended formal garden.
I've read various software architecture document pundits advise
"document in one place only." A decision model helps with having a "proper
place" to put decisions and the models and descriptions that explicate,
rationalize, contextualize, defend, advocate, and guide the implementation of,
these decisions. But, of course, it you create a reference document and a more
consumable-by-all-stakeholders overview document and/or presentation (set),
you've put things in more than one place. More to maintain. But we have to start
to see the architecture being worth the kind of attention it takes to both keep
an accurate reference along with more digestible viewports and keep these
up-to-date with the evolving architectural intent and realization. We have to
serve the advancement of the architecture by serving our own (core team's)
understanding of what needs to be done. And we have to serve those who the
architecture impacts in various ways.
A software architecture decision model provides an organizing
structure for decisions and the models and descriptions that explicate, rationalize,
contextualize, defend, advocate, and guide the implementation of these
So clearly we need to think about audience with an orientation that
respects their time and the outcomes they seek. My audience here is amazing.
Yes, smart with a great sense of humor, and humble (as only those most
comfortable with their rare qualities are), etc. But what I'm getting at is
that this audience is truly diverse with every continent
multiply represented by those who regularly stop by this journal. Some are at universities but for the most part
"you" are architects from across the spectrum of industries and public
agencies. There's also a spread in experience levels and job scopes. Well,
of course I don't know who you
are, but I get enough of a window to know there is this diversity. What, in
my assessment, is the point of commonality, beyond a passion for
architecture? Curiosity, an orientation to playful investigation -- that
awe-struck seeking. That and a gentleness, a desire for things to be better
in this world. And optimism. Glorious, irrepressible optimism! But,
curiously... this curiosity extends very little to following the links
within my journal. Apparently the view of the current month is more than
enough (to quench -- or drown -- curiosity and damp optimism)! Or perhaps
(optimism resurgent) my value is more as a comic scout than anything else.
;-) But -- I'm a great comic scout, aren't I. ;-) Nah. It's really
that those cartoonists are out there writing just the
perfect vignette to playfully punch up a
point I'm making. It's so markedly nice of them!
I write with candor, yes. But I also candidly ward off those with a
to human spirits (those who diminish people by imposing a small mental frame
upon them), with plenty of "warning: Q<= writes here" signs. (Hmm, yes,
isn't my New Year's greeting image utterly delightful? Sara is just
entering, and is totally taken with, the manga/anime world and is inspired
to learn Japanese as a result. If that didn't quite do it, there's the
diversity stretch sketch reminding us of undiscussables like how women
are really seen in technology.)
And for those who are just too busy, well of course there's the "warning,
warning, warning" of "words, words, words." Indeed, I drew the image
(above right) for the top of a journal page
2008, but then I decided the words themselves were amulet enough. ;-)
I have playfully said that it appeals to my sensibilities and sense of
humor that this journal both veils and unveils me, and googling the phrase
"veil of words" lest I be cliched (what horror!)... came upon two references
-- right above my site on the first page of Google results. They both relate
to, and are wonderful references (The
Problem of Perception and The
Veil of Signs) for perception! Which is the theme, to be playfully
illumed with magic, for that day of the Leadership workshop I told you about
last month. ;-)
Perception. A theme for an architectural leadership workshop? Well, it's
secondary (in the weft), but it threads through everything we do, doesn't
it? What impedes perception? How do we influence and persuade? How do we
communicate more effectively? What do we elide, so that we better elucidate?
These are all pivotal in architecting. And front-and-center matters of
A veil. A post titled a "note to persist" that has within it the most
pithy, most useful yet concise, guiding statement characterizing an
architecture decision model. ;-)
I write to educate myself. It is very much like architecture -- often we
have to expand, to add detail, to find the bare frame, the essence of the
explore in the shadows, not just under the light to find the key.
And it is value great to me if it stimulates questing connection making,
insight generating for you too.
And I write to celebrate the glory in the everyman. Yes, those whose work
is admired and which puts them in the spotlight of the public mind. But also
those who work quietly behind the scenes to make things better in the world
they impact, and in so doing, make things better in our world.
1/3/11 Building to Something
We become the ideal we hold out to ourselves:
First say to yourself what you would
be; and then do what you have to do." --
Epictetus (AD 55 - c.135)
"If you wish to be a writer, write."
-- Epictetus (AD 55 - c.135)
“Men acquire a particular quality by constantly acting a particular way...
you become just by performing just actions, temperate by performing
temperate actions, brave by performing brave actions.” -- Aristotle (384 BC
- 322 BC).
Again, we become the ideal we hold out to ourselves -- not absolutely and
without any compromise, but more, the clearer we make that ideal and work
towards it. Otherwise we just fall into others' (too often
Procrustean) views of us. (Procrustean? Think, for example, of the
over-ambitious mother - or father - who projects her ambitions onto her children.)
We may not (yet) have a sense of where-to, but following our bliss is
leading us. Sometimes we're incubating what we will become, without a clear
sense of what we might make of that, falling only to the draw of the dimly
sensed shape of our passion and the guiding/forcing hand of Serendipity and
the chance placement of opportunity and hurdle, the choices we make at the
various cross-roads and dead-ends our lives take as we accommodate our
aspirations and those of our families and colleagues.
I read this characterization of
today: "She was young, modest, private
and obscure, and did nothing remarkable, except struggle to be good."
I protest! That she did, but she also wrote vividly about her struggle to be
good; shared that struggle and its lessons. We build in ourselves the
capability to build in the world and our finely tuned sensibilities give
shape and beauty to what we build. I watch Sara and Ryan and I am staggered
at the work they do! Sara is constantly drawing, writing, dancing,
composing, creating and is mind-blowing fast at math too. Ryan is constantly
studying, analyzing, building a rich (and often hands-on) sense of the world
in various dimensions from music to literature to engineering and
bioscience. He is building a knowledge of The Lord of the Rings to
rival Tolkien's, I think! These are aspiring spirits and the work -- in
their work and in their play -- never stops!
Steve Jobs' "connected dots" (Stanford commencement address) is a great
lesson. Afterwards we may look back and see how the curious path of our
lives led to a "ding" but from here we may see neither the form the ding
will take, nor the relevance of what we are doing now.
The struggle to be good is a struggle indeed. And being kind to others
has to begin with being kind to ourselves. If we don't have a clear sense of
a ding we wish to set ringing across the expanse of this globe and of time,
but only that we hope some day to do that, then we need to let our bliss
lead us there. To do what we love, and to love what we do are
self-reinforcing, mutually building. We may end up being surprised at where
our various proclivities, riding upon the currents of destiny, bore us. But
for now, we have to trust that if we don't see "a big thing" worth doing,
then the seeming little things we do to make a difference (in our work, our
families, our local and virtual communities) are just as worth doing, and
worth doing with passion and zeal. Gentle action, touching ripples of
change, after all, is what changes the world in powerful ways. Following,
throwing ourselves into the dream another inspires, is as important as
leading, for big things aren't done without good following. And good
following is good leading, in the next circle of influence. You know,
leadership is fractal.
Um. I just thought I'd say that. Now I have to write about Leading. ;-)
And Innovation. And ... well, that I can't say.
This quote comes from a footnote to an architect's New Year greeting:
"The future belongs to
those who believe in the beauty of their dreams." ~ Eleanor Roosevelt
Those may be dreams we forge alone, or a shared dream forged in the crucible
of a team, or just as validly, we may fall into the embrace of another's
dream. Regardless, these dreams -- what we see but barely yet begin to build
chipping away at uncertainty until the dream, the difference we set
out to make, is realized -- create a better world. Yes, dumb luck, bad luck,
good luck -- and any other form you think Serendipity takes (perhaps the
guiding hand of angels or the ripples beyond ripples in the wake of all from
geniuses to hapless fools) -- plays its hand. But we sentient beings aren't
happy simply to cast our lot to the indifferent winds of fate. We wrestle to
make things and states of being different in our world.
Since you are so patently bad at following my suggestion (hrrmpf), I'll
quote myself rather than giving you the link (oh come, I tease, but only
We aren't mere windsocks
responding to the direction of the wind; we make wind!
Yes, my trademark double entendre. In context:
One other flaw in much of the
"we must respond to a changing world" thinking is that it neglects our
impact on the world. We aren't
mere windsocks responding to the direction of the wind; we make wind! We
change the course of history, in small and big ways, with what we create.
We change expectations about what is possible. We interact with destiny,
don't just simply bow to it. Though, to be sure, we ignore these forces at
our peril. But ignoring our role in shaping expectation, shaping the world
into which our systems will fit, is just as one-sided as blindly expecting
users to force-fit our product offering to their needs. The world of
pragmatists is the world of balance, the world of tradeoffs. This is just as
true for the process we adapt to fit our needs as it is to the products we
And since I seem to be quoting posts from previous Januaries, here's another
dose of my quirky sense of (un)humor:
Yesterday, I exasperatedly told Sara she was a
revisionist. She asked "What's that?" I told her it is someone who revises
what's happened. Without a moment's hesitation, she said "I believe that's
called a reporter." At 10, she's developing a deliciously dry sense of
nights ago, picking up Ryan from his friend's house, the father turned to
the mother saying "we really have to replace this light bulb." It was on the
tip of my tongue to say "Yay feminism!" But then I thought I'd have to
explain that I have a dry sense of humor, which directly led to the thought
"dry sense of humor? You know, when I get it, but no-one else does." Which
is one of those meta kinds of irony-ridden (so dry it that sucks all the
moisture out of the universe) self-flagellations because then dry is a
category of pseudo-intellectualist pseudo-comedy or ... the real deal... but
how would you know? The people outside the circle don't get it, and the
people inside the circle simply hold the same delusions of meta grandeur.
All of which was so exquisitely captured in one of my favorite (and oft
sketches--right down to the wasteland with all the
moisture sucked out... and the meta comment about perspective...
"A challenge for IT is how to provide
structure and process for business-focused technology R&D. Enterprise
architecture (EA) groups have the best set of skills within IT to do this by
managing the firm's innovation pipeline and developing the firm's innovation
network. But EA groups must recognize the role they should play in this to
enable the pipeline to be as productive as possible."
"Whether it was because they were
technical by nature or if it was
just more fun to play in the
technical realms, Enterprise
Architecture in most organizations
has become the bastion of standards
and policies, but one that spends
very little time actually talking
about the business strategy."
introductions Enterprise Architecture allows a proactive approach in
assessing the adoption of new technology and innovation. Technology
and innovation is often assessed reactively, rather than against
future business capability requirements. Projects maybe delayed
while time-consuming technology evaluation takes place; there is
also the risk of a project-focused evaluation rather than enterprise
"The aim of this conference is
to examine how information technology enables and generates
innovation and thus provides value to enterprises. The goal of this
conference is to discuss and share best practices, experiences,
models, methods and tools for innovation and enterprise renewal."
Conference on IT Enabled Innovation in the Enterprise -- ICITIE 2011
"In today's global world-and
due to the perfect storm of economic crisis, unprecedented
competition and limited access to capital that we've experienced in
recent years - people are longing for leaders who can anticipate,
rather than react".
Hybrid thinking combines the analytical mastery of
architects with the intuitive originality of designers. Hybrid thinking drives
change via the co-creative exploration of meaningful human-centred experiences
when confronting complex, intractable issues, also known as “wicked problems.”
"... I have often found
dynamics modelling of the cause and effect relationships between
objects (causal loop diagrams, stock and flow diagrams), popularised
by Peter Senge’s The Fifth Discipline book, to be a useful
approach for analysing how a system works. iThink is a nice tool for
doing this sort of modelling."
"I agree that you need a steam-release valve
when innovation comes along. But I'd like to point out another
commonality - in all your examples the actor provided the answer,
fully grown, like Botticelli's Venus. The establishment was backed
in a corner - they had to be 'wrong' for the idea to be right.
Luckily EA teams need not take such a 'wooub' approach when
envisioning the future, and creating rules.
opportunity to create joint ownership as the vision and rules evolve is a bit
better, and agreement as to the governance approach.
"That to secure [This Strategy], [Enterprise Architecture]
is instituted among [The Corporate Hierarchy], deriving their just powers from
the consent of the governed — That whenever any Form of [Enterprise
Architecture] becomes destructive of these endsden cl, it is the Right of
[Senior Management] to alter or to abolish it, and to institute new [Enterprise
Architecture Team]," - with apologies to T. Jefferson."
-- Anthony M.
I'd like to refer you back to my post on Architecture Principles (note the duration discussion and the
scope clause). Nick makes a good point, though it is not
inconsistent with the way we talk about principles. It is worth
highlighting the importance of the "open door," the willingness of
the architect to (re)consider the (innovative) ideas and objections
of those impacted by the architecture. The "crying
towel" notion only says that if the architect decides that the
architecture decision needs to be applied (granting no exception or
amendment in this case), then it needs to be applied or the
applicant needs to seriously weigh invoking due process
(governance). Why? Because the architect needs
to be open to better ways to do things, but also is responsible for
system outcomes -- for making something strategic better. That's the architect's judgment call. It is important for
the organizational culture, with the tone being set by management
and other technical leaders, to support the architecture and
demonstrate good following, but
governance generally allows for an escalation path to arbitrate and
provides a higher level of decision authority the option of hearing a
case for exception (innovation may, after all, impact strategy). You
don't want to be in a situation where the governance process gets
snarled up with endless exception requests -- that would be a sure
sign your approach is being seen as heavy-handed/heavily
constraining... It may be the right vision, but how you get there
might need revision.
Leadership isn't just about setting the vision, but how
we get there not by mandate and commandeering, but drawing people
in, aligning and empowering and drawing on the best in them to
accomplish that vision. Yes... To Lead is to See, to Frame, to Draw...
Caveat: A leader may choose to use some mandate supported either by
organizational authority (like power over resource allocation) or
passion and charismatic emotive force -- being dramatically (and
authentically) stern when core values and principles are
jeopardized, breaking and rebuilding rapport, etc. But there is a
"sliding scale" -- one that is easy to slide down and harder to get
back up -- from organic, empowering, collaboration-enabling
leadership to command and control-styled dictatorship.
And seasons turn. We see plenty of organizations (from projects all
the way to the corporate level) flip-flop between the yin and the
yang of network-facilitative and command-and-control dominance
styles, for too much of one gets seen as the ill that has to be
addressed, and seeking correction, the other extreme is promoted.
How many times have you seen this: Network facilitative leadership
gets something ambitious going. But the project takes longer than
anticipated (Hofstadter's Law) and the management team gets antsy,
there's politicking behind the scenes, and either the project is
cut, or a more authoritarian manager is brought in to set things to
rights, the pressure gets turned up, and the thing gets done.
Compromised, but done.
Well, a day in the hype spotlight generally means there falls a
night of hype-backlash. Has architecture fallen into this shade?
I was watching a presentation on agile and a key thesis was that
heavy-weight plan-driven processes have roots in Taylor's scientific
management, in which processes designed by "process experts" are
imposed upon workers. Agile, by contrast, it was argued, holds that
teams choose what process to follow.
Perhaps a useful distinction to rather make would be that agile
processes are (in their best incarnations) organic and adaptive. They don't prescribe
finely compartmentalized and routinized work designs. Those who
promulgate the likes of SCRUM and Kanban, TDD and continuous
deployment, and VAP, have distilled lessons of experience across
many projects to provide some level of "scaffolding" so teams can
leverage what has been learned (rather than learning the process
lessons from scratch every time, which is as much a waste as
developing all of a project's infrastructure and development
environment tooling from scratch each time or re-inventing patterns
over and over, and over). Some of these processes, like VAP, enable
collaboration, communication and integration of work so that more
organizationaly and cognitively demanding (more complex, and requiring deeper and more
varied specialist expertise to be bought to bear) systems can be
built -- created, that is.
Yes, VAP. For the first few years, we balked at giving VAP a name,
because to us it is just what architects do, organically scaling up
and down with the organizational and system complexity and state of
maturity (or lessening degrees of freedom) of the system. Then we
found clients calling it the "Bredemeyer Process" and we balked
still more at that, so called it Visual Architecting to place an
emphasis on the visual (integral to the collaboration,
conceptualization and communication inherent in designing systems to
be built with and through the empowered contribution of many minds
-- and impacted by the whole person that houses that mind). The key
has always been that architects have an enabling toolkit (along with
models that organize, but by no means dictate, the decisions, views
and threads of reasoning), but architects decide what is
architecturally significant for their system, and how to go about
addressing only what is, to the extent necessitated by a commitment
to realizing strategic system outcomes.
In Taylor's day, things were incredibly different than they are now.
Route processes that could be optimized and standardized were
performed by humans, and yes, they were often more efficient, in
this paradigm, following the designed routine set for them. This is
not to say that all processes were route, but where they were
amenable to rendering work repeatable, finely compartmentalized and
routine, the improved efficiencies earned advocates -- along with
criticism for the human toll on quality of work-life and reduced
bargaining power for now much more "plug-and-play" workers who could
be quickly trained to do repetitious small chunks of work. But
today, such mechanistic processes are increasingly mechanized and
automated. As fast as we can, we have replaced human workers with
robots and automation in factories (well, this is still ongoing, but
the transformation of manufacturing has been massive), and
digitization has been moving into service realms apace. This is the
march of lowering costs and improving productivity and increasing our
ability to accommodate and advance the complexity inherent in human
accomplishments and technology-enabled products and services. We've
been creating products and services that have reshaped our work and
personal lives in diverse and pervasive ways.
The development of those products and systems, on the other hand, is
anything but routine. So the processes we talk about in development
are of quite a different nature to those where the work can be
routinized. They have more to do with the co-ordination of complex
highly cognitive work. If we place value on small, highly empowered,
self-organizing teams, and at the same time we want to create
complex systems, we have to provide sufficient context so that the
system will have integrity and be sustainable.
That "sufficient context" is dependent on system and organizational
complexity. I so often see discussions of agile, especially those in
the offensive against Design Upfront, proceed with no reference or
sensitivity to the role of complexity and uncertainty, challenge and
risk. The more complexity, the more minds we need to engage to
create the system, the more we need to do upfront and along the way
so that we get a synthesis with system outcomes that are better than
an aggregation of disparate, poorly integrated parts. Yes, yes, we
want to do just enough upfront. And we want to start to seed fan-out
as early as possible, involve more people, leading people. (I said
minds right there, but then I caught myself because people bring
bodies and moods and physical states and abilities that are not only
cognitive, etc., etc., to the process so I scolded myself for
focusing only on minds. ;-) Discussions of KANBAN, for example, may never mention
architecture or architects, and give the impression that we "don't
need no architect." But as soon as we seek to build complex systems
and scale any of the Agile processes and their derivatives, we start
to see Agilists reaching over the divide (they drove, marking out a
territory for Agile to claim) to architects and architecture (just
enough design upfront and more along the way).
So, no. I don't believe architects are obsolete. Because design is
not obsolete. Quite the contrary. Though we orient ourselves to
doing just enough design upfront.
I think, in part, some of the bubbling
resistance to the "architect" notion has come from shining a well-intended
light on the other skills of the architect, beyond those that are purely
technical. We bear a good part of the responsibility for that, having led
into that arena, but various architect certifications have added mainstream
awareness of these other dimensions of the skillset. So, for the record, the
technical skillset (honed in the development of systems, and supplemented
with what others have learned through patterns and other vehicles for
packaging the learning into consumable form, including processes like VAP
;-) is absolutely fundamental. The thing of it is though, our experience and
degrees are typically in the technical domain, and we gain this experience
for the most part giving a computer instructions, and to be sure, computers
have their own way of being obstinate, frustrating and then yielding, but
grudgingly, to our persistently plied attentions.
Programming is, after all,
thinking, but thinking and trying can beguile us into more trying than
thinking. Regardless, coding (even pair programming) is different than
making decisions (alone or in a team) that impact various stakeholders,
often many and quite varied stakeholders. Architectural design is about
leverage, but it is also about (from some points of view) compromise. So
negotiation. Persuasion. Influence. Leadership. And we find ourselves
tumbling into a space of skills we didn't much need when being productive
meant we got to have serious personal time with a machine. It is the lack of
preparation for (and, frankly, often the lack of admiration for), and the
make-or-break importance of, the "soft skills" dimensions of the role, that
causes us and others to highlight them. But it does make for surprise for
those who haven't been noticing these attributes of the architects that are
effective in the organization. We so often look for role models among people
who are like us, rather than among people who excel at what the job we're
eying needs us to be good at!
So, for example, if we say the architect needs to have skills in the
strategy space, this can be a red flag to the proverbial bull, raising
counter that this is bs of the highest order since architects do not set
strategy. Au contraire! Architects set technical direction (sometimes others
do, but on what basis?). And direction setting is strategy is it not? And
technical direction shapes and constrains business direction. (Think
MySpace, and you'll see my point. Yeah, it's an extreme case, but extremes
make a point extremely vivid.) So technologists need to savvy up to the
impact of technology choices that create direction that impact what is the
effective (emergent) business strategy. Managers too. That recognition,
then, means business strategy setters do well to take input from architects
(at the relevant level of scope/seniority) who understand technology
capabilities and think strategically about technology trends, and
technologies in other domains that can be leveraged into capabilities in
their business domain, and so forth. Value, after all, is created through
integrated "bundles" or webs of capabilities. Ostriches may not stick their
heads in the sand to avoid acknowledging threat, after all, but we do if we don't acknowledge the
link between technology strategy (and implementation) and business strategy
in this age where business systems and the products we create are
Ok, perhaps you're nibbling, not quite persuaded, but some of your
reservations are being shaken up just a little...
Perhaps, then, you counter, this is all very well for senior architects, but
not entry-level application architects? In
The Art of Change:
Fractal and Emergent, we argue for viewing strategy and architecture in
fractal terms -- emergent too, but importantly, in pools of strategic
influence that vary in scope/impact. So we think in terms of product or
service strategy (narrow scope), through increasing scope to cross-cutting
strategic initiatives and corporate strategy (enterprise scope).
Well, how do you gain strategic competencies? By acting strategically -- by
thinking in terms of creating sustainable value. Sustainable in... yes, the
refrain if you please -- sustainable in every sense of the word from
technically to economically and environmentally to morally and personally.
I'll burn this in, I will, I will! ;-) And then, just think what a
transformation we'll have, when ripple by ripple ever more architects have taken
moral ownership for dealing
not just with structural contingencies but
structural viability through change and other impinging forces,
system's effect on people, real people that use the system as well as those
who will live with evolving it (no more shanty town systems),
sustainability of the business and
humanity's viability as a presence on
Oh, I'm kidding, but only about my role in initiating a gentle
wave of change -- for many before me, and many besides me, are tipping these
ripples of change. I only add my voice and "gentle" wallop of words... ;-)
Uh, I didn't expect that to
go there... Let's see, where was I... Ah yes, addressing those just
transitioning into the architect role at a narrow scope of influence and
decision authority... Or, more likely, those who are concerned for those
contemplating or assuming the role. The former being unlikely to have gotten
past the child-like/ish/girlie manga at top of this page. ;-) Ouch! Right?
Procrustean frames) are
damaging and unfair. I didn't really put that image there as an amulet,
truly. I only tease myself with that reflection, because I know that my
(delightful?) choice of New Year's greeting will have that affect on some
people (but not people in a specific role, just busy people needing to
manage their attention with quickly cast assumptions based on the obvious
cues or signals presented to them). My teasing within teasing (of myself) is
about the ironies implicit in wanting an audience that values what I do, but
providing very little to attract an audience; rather providing all the cues
and substance that would put an audience off!! [Allowing this paragraph
within an entry that otherwise might have some small impact, for example,
undoes any likelihood that someone could recommend it. ;-)] But... since
no-one else will read this... I'll ask just you... isn't it genius indeed to
title this post 'sense and sensibility" -- a reference to Jane
Austin's first novel, exploring our various follies and foibles especially
stereotypes or group expectations? (Though set in the early 1800's it
reads well today, for example, if you translate the conceits and fashions of
the day into those we encounter in the technology space). Ah, but the novel
is also about the goodness which in most of us manages to be ever resurgent
despite our repeated lapses into foolishness. Ok, ok, I mean genius in the
Elizabeth Gilbert sense, or Sara's "voices in my head that are not my
own." Voices that arise out of the parade of minds we've encountered and
allowed to bed down in our own, fathering thought children... Uh, let's get
back to the point. Not that we diverged from it, those with highly tuned
sensibilities will note. ;-) Huh? Well, the point is that there are notions
of the architect role that delimit it as a technical role. So, simply a hat.
So a hat everyone on the development team can wear. So no need to make it
explicit. So... no leadership. Erosion. Ball of mud... Yes, it is a
technical role. But it is more -- it involves bridging, translating,
The point is that we need to start seeing the systems we create in
strategic terms, and partner with business leaders at the relevant scope to
create strategies that create value for customers, the business, developers,
and others in the value network. But not just any value. For, given limited
resources (talent, time), we have to make choices. Strategic choices.
Choices that impact sustainability -- competitiveness in tactical frames
without undermining future viability (technically, competitively,
organizationally, socially, personally, environmentally). Personally? Well,
for example, high degrees of "technical debt" (a nice businessy sounding
gloss for a "#load of mess"?) create high-stress work for those who will
inherit the burden of system evolution. High stress? Ever had to make a
change to a "hairball" that your business depends on?
Technology has woven itself in the very core (in Geoff Moore terms, too)
of the business. Our value networks and businesses are becoming ever more
"monitored" (analogous to patient monitoring in hospitals) with information
gathering devices and artifices, and turning the deluge of data these
"sensory inputs" create into intelligence-led actions is a matter of
strategic thinking (the deluge must be mastered or the utility will be
washed out -- that classic "information costs attention" Herbert Simon quote
comes to mind) to channel, direct, focus excellence in tactical deployment.
Just processing more data, no matter how academically (meaning outside of
the context of our business) impressive our analytics, isn't going to make
us smarter without making smart choices about where to focus attention and
resources. On and on we could go with examples, but the point is that our
businesses depend ever more on technology, and this technology is ever more
interconnected because that too creates business value and opportunity, so
the wicked problems of business systems reach tendrils ever deeper into
other systems and all of this is strategic -- make or break for the business
and a matter of setting vision/direction (which is a matter of making
choices about what value to pursue in the context of alternative, competing
demands on limited resources), strategizing on how to realize the vision and
leading the execution of that strategy.
Architects bring technology savvy to the business opportunity-seeking,
framing, leading partnership of the strategy team (at the relevant level of
scope). Which means it behooves the architect to have good strategic sense
and sensibility -- blink intuition, and smarts born of paying attention to
and learning about the business impact of technology, technology directions,
and so forth (this gets too long already), relevant to the products/services
and markets or webs within the value chain that the systems the architect
designs fit into. Well, it behooves the architect if his/her organizational
context allows him/her to accept the challenge of creating sustainable
systems. It is certainly true that in many organizational contexts the
(so-called) architect's role is circumscribed to technical heroics, fighting
on-the-line fires and saving the day -- today. Each and every day. Or coding
the really challenging pieces of systems. But these aren't architects in the
sense of being responsible for system integrity (design and structural
integrity). These are technical specialists with admirable and crucial
technical know-how. Yes, architects must have that too, and may well play
this role, (importantly) keeping their hand in the game and maintaining high
technical cred on the team. Just, not all the time.
4-day Software Architecture Workshop in Palo Alto/Los Altos, CA on March 21-24, 2011. Note:
There is an early enrollment discount of:
- $400 for enrollments completed
The early enrollment discount is there to try it to encourage enrollments soon (if we can
guarantee a higher participant minimum that impacts the venue
pricing, and in Palo Alto, that signifies).
The Embedded System Institute is running our Software Architecture Workshop (with Dana Bredemeyer
instructing) in Eindhoven, The Netherlands on March 29 - April 1, 2011.
Last September this
class was full and waitlisted early, so enroll soon!
It is always good to have a spectrum of experience in the workshop,
and senior architects do typically find the workshop valuable. They offer
in insights, guidance, stories and lessons and validating the
importance and relevance of what we cover in the workshop. Mark
Mullin was one such senior architect and he characterized the
workshop as "collegial" (on LinkedIn) and I really like that way of
putting it. I tend to use the crucible word, meaning everyone gets
to put questions, content, stories, lessons, guidance into the
"crucible" of the workshop, providing a rich mix from which
participants compound and draw forth the insights that illuminate their path and
their work as architects. All voices are respected and
encouraged, and that level of working in the large group and small
teams is an enormous part of the value of the workshop. It is a
great time to back out of all the pressures of the job, and reflect
on what works and what creates impedance and how to be more
effective in making architecture decisions that truly make the
business more successful.
decisions are technical, what makes them fail or succeed is very
often not! Wrong decisions may be a matter of ill-advised technical
choices or a matter of not getting what the real criteria are (like
political crud that has tendrils wrapped all over the decision but
which those of us with weak political sensors just aren't noticing,
or we think that pay-check drawing folk should just get on with
doing the rational thing -- you know, what we have decided). Or the
right decision may be misunderstood or balked at -- for many
reasons, from orneryness and habitual push-back to real concerns
about the side-effects of the decision. Etc. Stuff. Happens.
So we work on all these fronts--technical, business, organizational
and personal effectiveness. Working with very carefully selected
"Pareto" tools so the technical decision process is supported, and
we realize a minimalist architecture that is good (technically
sound), right (meets stakeholder goals, addresses--on balance, or
reshapes--their concerns/frustrations/aspirations, etc.) and
successful (is actually realized and shows value--from early days
through delivery through a vibrant evolution to obsolescence by the
Well, hopefully that has you eagerly rushing over to sign up. But remember, bring some of your colleagues along too.
They will see what you are trying to do, and why you do what you do,
in a new light, and it creates common language. Our explicit goal is
to inspire and enable, so when we all (participants have to pitch
in) succeed, you leave impassioned and with an enabling toolkit and
organizing models to guide the choice and application of the tools.
Or... something like that.
But if that didn't do it. Let me remind you. The workshop is in Palo
Alto (actually just on the border between Palo Alto and Los Altos)
-- yes, the Bay Area/Silicon Valley. You can bring your family (it's a Residence
Inn, so family-friendly). There's plenty to do in/around Palo Alto
-- visit Stanford and even if you don't make it to the art museum
during opening hours you can go to the Rodin
sculpture garden, and to the bookstore (and see Rodin's Burghers of Calais; The Thinker is on loan in
North Carolina, which is too bad because as you see from the top
of my page, The Thinker is important to my identity). Visit the Computer History Museum in Mountain View, and see displays in the
Gates Information Science building at Stanford. And go up to the
city (San Francisco) or cross the Bay to Berkeley (go to Bette's Oceanview Diner for
brunch--no view, great food). Head over to the coast (we lived in Moss Beach and can give
you lots of pointers to hikes and restaurants). Dana taught kayaking
in the Bay, so can give you pointers and tips. Etc. Take the spouse
off to Napa for the weekend. Whatever. It's a glorious part of the
world! Dana and I will be fighting over who teaches this one, but if
he wins out, I'm bringing the kids! ;-) [Actually, Dana
usually insists I do the open workshops because he's so booked up
with existing clients, and he learns so much from me he thinks other
architects should have that opportunity too. I love facilitating the
workshops, but from time to time someone has um reservations about
my quiet voice and thoughtful, non-assertive style and my spirit
wilts at that, so I'm always ready for Dana to do it. Besides, I
learn so much from him, I think other architects should have that
opportunity too. ;-)]
Oh, and if you're totally into doing this, hopefully your manager
will read this and translate it into doing more to develop and enrich
the work lives of the talent (not to mention the IP embedded in
their heads) they want to keep, so he/she will champion (even beg,
borrow and steal) the budget to enable you to go on this boondoggle,
um, I mean go to a training that will put you on a high velocity
path to creating sustainable advantage through technology. ;-)
Just... don't let your manager read this. The overview on the Bredemeyer site will have to do. [Word to the
wise manager (only wise manager's read here) -- let your architect
think the boondoggle was your idea. Don't let your architect read
this. The overview on the Bredemeyer site will have to do.]
Or... just keep reading my journal... and papers... and the book...
and you'll get some of the value. But remember, conversations change
the world. You will be different for entering into the lively
conversation of the workshop. The other participants and I (or Dana,
if he's lucky) will be different. And the world will be different,
for the greater impact we'll have. Reading is a controlled
interaction where we choose what to take and what to leave so we
tend to do more leaving if the material isn't quite what we thought
we wanted. Yes, some of that happens in a conversation but the less
so, the more we enter with a spirit of goodwill and yield to the
sometimes leading, sometimes following, interactive flow of the
The point about conversations in the last paragraph owes much to a
conversation I was having with Dana. It will change how I talk about conversations, which
will in turn impact other conversations. A good many architects
expect that the confining boundaries that surrounded them in the
cloven "divided by specialty" work-world (where, for example,
developers don't talk to marketing, let alone customers) still
surround them, and it is a big ah-ha to find that the architects who
are successful are working outside those boxes, having -- yes --
conversations within but also outside the development team.
Conversations change the statespace -- the content, like knowledge
and ideas, and the attitudes
-- of the architect and of (other) stakeholders. The architect
starts to be seen differently, because the architect starts to act
from a different statespace as a result of the interactions with
stakeholders. These stakeholders know their concerns are being
brought personally into all that must be factored, and they have a
better sense of what is being weighed and balanced, synthesized and
sometimes, yes, compromised but for the good of system outcomes.
We rational, objectively thinking engineering types can forget that
the attitude part -- not just the knowledge and reasoned argument
part -- of the statespace tends to be the bigger factor in getting
things done with and through people. Including ourselves, for
managing our own attitude is where it all starts. Lack of
enthusiasm, goodwill and joy dulls our own ability to imagine and
sculpt "clouds" into realized things. Fortunately, a lot of what we do to sculpt
"clouds," carving a dream we share into reality, in Visual
Architecting works on the state space -- the knowledge and
decision space and attitudes, feeling, passion -- at the same
time. If we do the right kinds of things sometimes with other people
(sometimes alone and then together, sometimes in small groups,
sometimes in large groups, pulsing dynamically) we can have the
process do double duty, making formal progress and informal organic
1/6/11 Design Thinking
Note to self: According to wikipedia: "Synergy can be understood as the opposite of
the concept entropy." Opposite? I need to think about that...
With increasing entropy, there may be decreasing synergy, but I'm not
immediately getting that the concepts are opposite...
Ok, if you watch this Jim March lecture-film, Don Quixote's Lessons for Leadership, and don't find it the most
transformative, most you-affirming, ultimately career-enabling hour
of this year... my brand of useless is indeed useless. ;-)
Now aren't you glad I told you early in the year? (And if you knew
about it, why didn't you tell me 7 years ago? Huh? Huh?)
As for me, I think I was just given permission/encouragement to keep
filling my wild landscapes, insane as that might seem! ;-) You know,
Stanford professor emeritus Jim March is listed by many in the
"establishment" line-up of "thought leaders" as their guru or
mentor. I generally dislike parties (I'm introverted and outside of
architecture not a social creature) and I'm late to
this one, but I do like his irreverent stance towards the staid
norms with which we bludgeon fellow "workers" into conformity and
compliance. I guess I'm going to have to re-up on my HBR
subscription so I can read what March had to say about:
aesthetics, leadership, the
usefulness of scholarship, the role of folly, and the irrelevance of
relevance when it comes to the pursuit of ideas
-- Ideas as
Although... I don't like being put through that "Procrustean
treatment," so best to avoid raising the possibility...?! Wild
landscapes are hard to get to for a reason, perhaps...?! :-)
It is instructive, though, how Serendipity -- you know, the perhaps
name of angels ;-) -- weaves its threads, reasserting a lesson
it wants to teach if we don't at first pay heed. The other day,
Daniel Stroe pointed me to Dostoevski's The Idiot and Kurosawa's film
interpretation. [No, nobody -- not even I, in this case, though
I am apt to -- was implying I'm an idiot, but thank you for your
protest at the thought. ;-)] I like Kurosawa's response to the reaction that the film was too long:
"cut it in half length-wise!" (Think that would work with my
journal? ;-) I responded "I love the references,
and the reminder that being thought a fool by fools has more merit
than otherwise." That was too glib. Serendipity had more work to do
on me. So, Don Quixote. I'll have to attend better.
We are paradoxes within paradoxes, we sentient
creatures! How hard we try to be rational and gain control,
submitting so much of our sentience to the leveling expectations
society -- through our own mediation -- imposes. And even when we
know, rationally, that it takes a seeming irrational advance to
break with current thinking and confining convention and address
something that is wrong in the world, we lash at the fools who by
dint of fantasy, folly and obduracy (what in ourselves we call
imagination, resilience and discipline) seek to make something
different into the world. Ah, but again, balance is key. Not so much
moderation as to be too timid to act. Not so much immoderation as to
be cast outside society. We have to trust our sense of self, the
passion that lights our will to lead, and our sense of what to do
about something that needs to be done!
That phrase "through our own mediation" calls this quote to mind:
"No one can
make you feel inferior without your consent." -- Eleanor Roosevelt
Image by Sara B. The sketch relates well to Jim March's
inspired use of My Neighbor Totoro in Don Quixote's Lessons. [I haven't seen all of Hayao Miyazaki's
films, but I've loved all I have seen. I can't tell you how many
times the kids watched Kiki's Delivery Service and My
Neighbor Totoro when they were much younger. We enjoyed watching
them once or twice too. :-) Sara
loves Howl's Moving Castle, but I haven't yet seen it. Dana
bought a toy Totoro for each kid back from Korea one year, and now
the kids have outgrown them, I find I have grown into them! An
emblem of imagination, indeed!]
"This book considers the unexpected problems
organizations (and the individuals in them) face when they rely on
experience to adapt, improve, and survive.
acknowledging the power of learning from experience and the extensive use of
experience as a basis for adaptation and for constructing stories and models of
history, this book examines the problems with such learning. March argues that
although individuals and organizations are eager to derive intelligence from
experience, the inferences stemming from that eagerness are often misguided. The
problems lie partly in errors in how people think, but even more so in
properties of experience that confound learning from it. 'Experience,' March
concludes, 'may possibly be the best teacher, but it is not a particularly good
You know, someone should tell Jim what I say: Lessons are best
learned from experience--someone else's.
Yes, there is some strength to the argument that architecting skills
are learned from experience--but the lesson is always much less
costly when it is from someone else's experience! --
moi, Bredemeyer website
"Always" is one of those extremes that are valid only in extreme
cases, but I'm sure you get the humor in my extreme-ly vivid quip.
But what I mean is that we learn much also by integrating
"knowledge" (the synthesized lessons of those that went before us)
into action, into learning by doing, and then we learn still more by
reflecting. And we learn from those who reflect on what is learned
by doing, synthesizing and distilling and organizing knowledge (from
the very practical and task oriented to the more abstract and
orienting) into useful forms. We progress by this process of
integrating and extrapolating/projecting and extending/reapplying in new ways,
reflecting/extracting/organizing/relating/synthesizing and more. Not
all learning by doing. Not all "ivory tower" learning by reflecting,
scholarly investigation, and scholarly discourse in ideas and their
application and relationships to what is known. Craftsmen play an
important role in showing what can be done with acute attention to
learning by doing, by engaging hands and head. Scholars play an
important role too. And others who pulse more between doing and
How DecisionsHappen! Happen -- that's not a chance word. I need to read it
So, architecture documentation -- is that how we take blink
intuition, emotional content, political engineering and reasoned
analysis and allow decisions to happen, then cast them in
rationalized terms... and communicate them to people who will
rely on blink intuition, emotional content, political engineering
and reasoned analysis to grok them... ? That sounds both easier and
harder than I'd thought!
Bliss and serendipity. The perhaps names of our internal and
Buckminster Fuller's motto was "Dare
to be naive." We can get so
worldly wise, so silted up with experience and know-how and
know-better, and adulterated by cynicism we stop reaching for the "unachievable." What the
skeptic thinks a folly to try is just a breakthrough opportunity
someone will make the most of. If we can put aside our
sophisticated views and just dare to be naive, to imagine, to dream,
we open ourselves to what is possible.
"Why should you want
to give up a child's wise not-understanding in exchange for
defensiveness and scorn, since not understanding is, after all, a
way of being alone, whereas defensiveness and scorn are a
participation in precisely what, by these means, you want to
separate yourself from."
-- Rainer Maria Rilke, Letter 6, Letters to a Young Poet
Once in a while I act like a
child to feel like a kid again
It gets like a prison in the
body I'm living in
Cause everyone's watching and
quick to start talking, I'm losing my innocence
Wish I were a little girl
without the weight of the world
It would be nice to start over again
Before we were men
I'd give, I'd bend, let's play
Remember the times we had soda for wine And we got by on
The worst they could do to you
was check your attitude
Yeah when fights were for fun,
we had water in guns,
It's not going to be long before
we're all gone with nothing to show for them
Stop taking lives, come on let's all grow up again...
Childhood is an amazing thing, and innocent unadulterated optimism hard to
sustain, but we can--do need to--skim off clouding pessimism, and maintain an
open-hearted belief in the goodness in people! We can dance amidst all that is
real, see it in its squalor and its glory, see the tawdry and the magnificent,
see all of the contrasts between smallness and greatness, and know that such good is possible.
Always. And at any moment!
"the writer is delegated to declare and to
celebrate man's proven capacity for greatness of heart and spirit—for gallantry
in defeat, for courage, compassion and love. In the endless war against weakness
and despair, these are the bright rally flags of hope and of emulation. I hold
that a writer who does not believe in the perfectibility of man has no
dedication nor any membership in literature." — John Steinbeck, Nobel Prize
Acceptance Speech, 1962
We just have to disabuse ourselves of know-better! Of defensiveness and
scorn. [And the necessity of writing full sentences. ;-)]
1/16/11: My father set context for my childhood with his "positive thinking."
He was joyful in spite of his troubled life and wanted to do things the good,
right way, even when it was the hard way. So he did odd things like insist on
farming his smallholding (in after-work hours) with no chemicals. No pesticides.
No fertilizers. Remember, that was when I was growing up--that is, before organic was a "thing"; that is, before you could charge a price premium to cover
the additional labor and crop risk. Last night I watched Cross Creek. It
is the kind of thing that whose who cast movies that way would call a Q<= movie,
but I wanted to do something that was a celebration of women, at least my kind
of woman, and picked just that movie (sorry, but sometimes the world is a tad
mean and I just needed that). It was what I hoped, and it was also a celebration
of our connection to the earth and a reminder of the ways in which my father was
Image: When the Tiger Woods
hoopla broke loose, I wondered what Accenture would do. This (above)
was in the airport in Chicago (photo taken by Dana when we passed
through on New Year's Day, 2010)... I don't know if it was just
serendipitous timing, but it made us laugh and grab for the camera!
The image speaks volumes doesn't it? When you're in the rough, what
you do next counts. But who wants to be in the rough? So it's not
what you do next that counts -- not when we take a long view. What
really counts, is what you do to not get in that spot. That's integrity. It's hard.
It's a matter of tough choices. Of pro-active action, and at any
misstep or fumble, ever drawing back to the path we set true to our
identity (mission, values, sense of meaningful purpose, etc.), our
Active reading engages us in a conversation between the voices in
the writer's head reflected in the writing, and the voices they set
conversing in our head. Even people long dead live on in their
writing for reading brings their voice alive in our heads. Natalie
Merchant confessed to an adolescent girl crush on Robert Louis
Stevenson, adding that still today if he was to walk into her life
there'd be trouble, while Tim O'Reilly tweeted "If you want to fall in love with the mind
of RLS, read Home From the Sea." Ryan North, of dinosaur comics, heads
his comics blogroll "some comics I would TOTALLY MARRY." I
see a meme here, and I think it
is playfully yet insightfully talking about the powerful way we experience
this interaction of minds and how we incline to what we enjoy
reading. Reading happens in our heads where we most experience
ourselves as sentient beings. It is possible we'll take someone into
our heads to disagree with them, but for the most part, at least in the
reading we do as part of our "awe-struck seeking" we're going to
invite in voices we respect and like.
don't go in much for "gurus," but lean rather to the notion of muse.
It is perhaps a problem of (mis)interpretation on my part... Still, I think there is a danger of
placing and being placed on a pedestal that is damaging to the seen
and the seer. A muse, to me, is one who we allow to instigate
insight and inspire us. We don't venerate them because we know our
own role in the building of our self, our understanding and capacity
to build something great in the world. Yes, we allow our muse to
bring something new into our thinking, so we have new insights and
even extend the boundaries of our thinking. But we do this
ourselves. A guru lends us his wisdom; a muse instigates and stokes
our own. We pay deference to a guru; we pay respect to a muse. A
muse muses, and we use their musing like yeast in a bread (raising
our own musing). But we have to be pervious, to be susceptible to a
Now, one could wonder why anyone would choose a muse who is too much
like oneself. Sure, one wants a muse one likes to engage with,
but too similar a voice only confirms but does not help us bring
something new into view, does not provide fresh reflection only
images we've already seen in our self. It is validating to see that
confirmation, but we must also be surprised by our muses or they do
not serve to help us extend ourselves.
Muses risk opprobrium--they wouldn't be doing something useful if
they didn't bring something new into our experience, and a change in
view will have its detractors. Simply writing or speaking out risks
detractors! And when their thought leadership puts them in peril, we
may see them as heroic. But better, I think, for the muse and those
who allow the muse to be one to them, to brook no pedestals.
Oh, and to quiet a sniping voice in my own mind, let me say: To
write a muse off as some kind of self-help mumbo gumbo is to dismiss
the tradition of learning from others, the tradition of the
resourced intellect that leverages the great explorations and
discoveries of other minds to make more within itself.
-- if you think of doing something he'll say, let's do it. And then we'll do it the next day or right away. And usually get anything done-- to get anything done-- you have to convince a lot of people and make a plan and so forth. But I've worked with a few of these people who say, well if that's a good idea maybe, we can do it tonight instead of next year. So until the 1980's, I never wrote a proposal. I just was always in the environment where there would be somebody like Jerry Wiesner of MIT.
Nice as it is to hear Minsky tell his story, I can "hear" him through the
words of the transcript... and I found that if I forward the video to the end,
then I can read the transcript at reading speed. Phew.
I lol at this:
MINSKY: Senator Mansfield who was a great liberal decided that the defense department might be a dangerous influence and he got Congress to pass some rule that the defense department you can't do basic research. It should only support research with military application. It's a great example of whatever you want to call it.
That is such a great way of putting it! Of
everything that might come to mind given this story, this is a great example of
that! Given that, it only got funnier when the interviewer
tried to be helpful (and tactful or pc), adding:
INTERVIEWER: Unintended consequences--
Minsky would have none of that mincing:
Or shooting yourself in the head.
Of abstractions in learning, Minsky said:
Because you can think of any theory of learning as saying you've had a lot of experiences is there a sort of higher level, simple thing that they're all examples of. And Ray Solomonoff invented this other way of making generalizations. ... Ray Solomonoff's theory said if something happens you must make a lot of descriptions of it and see which description is shortest because it must have the most significant abstractions in it. Like if you could have a short description that gives us the same results as a long one it must be better or whatever.
MINSKY: ... this Occam's razor or finding
the simplest theory worked tremendously well in physics and it worked pretty
well in some other sciences. But in psychology it does nothing but harm. And a
simple reason is that we already know that the brain has 300 or 400 different
kinds of machinery. And they're each somewhat different. We know how three or
four of them work like a little bit about the visual system and the cerebellum.
But we don't know how any of the dozens of brain centers work in the frontal
lobe and the parietal cortex and the language areas and so forth. But one thing
we can be sure of is the brain wouldn't have 400 different kinds of machines
unless they were specialized and behave in different ways and do different
So The Society of Mind starts out pretty much in the opposite way and says, let's take all those things or a lot of the things that people do and try to find simple explanations for how each of those could be done. And then let's not try to find a simple machine that does all of those but let's try to find some way that a few hundred of these different things could be organized so that the whole thing would work.
That's kind of like designing a software system in terms of societies of
mechanisms. So... I'd like to know what Minsky has to say about analogy,
and analogical reasoning. Well, I need to read both books. I took an AI class
way too long ago (late 80's).
software architecture decision model provides an organizing
structure for decisions and the models and descriptions that explicate, rationalize,
contextualize, defend, advocate, and guide the implementation of these
decisions. It provides guidance and directs attention so that we don't miss
crucial aspects of the architecture, but without being directive and
prescriptive. Rather it allows for an organic process that adapts to
system and organizational complexity and uncertainty, challenge and
With the Visual Architecting Process map, we see how threads of
reasoning cut across design choices or decisions and the views that
express and contextualize many of these decisions -- we express,
think about and communicate many of our design options, then
choices, in models -- drawings of the design we have in mind. These
begin as informal sketches, reflecting early, formative ideas. This
format is a cheap design medium for exploring options, in good part
so that we can find promising or tricky areas so we can selectively
direct attention to opportunity, risk or uncertainty/"big buzzing
confusion" that we need to resolve better to assess our direction. Then, as our design ideas mature, we mature our rendering of them,
adding precision and formality, and disambiguating them so that we
can better presume consistent interpretation (without repeated
personal intervention to ensure design intent is communicated). Of
course, this is itself a process of discovery, of design, and as we
add detail, we find ourselves reconsidering earlier design
This highly iterative process, and necessary willingness to hold the
design in creative suspension, can appear chaotic to the outsider.
We're making choices to move forward, but recognizing them as stakes
in the ground that help us see what needs to be changed, which makes
for backtracking. We're exploring ideas and options. We're diving
into detail in areas we find important to clarify further, to find
an appropriate approach at a more strategic level. However, with the
Architecture Decision Model and an organic, iterative process, it is chaordic. A hybrid of chaotic (imbued in the nature of the creative
process) and orderly; of organic and (just enough) higher ceremony
An organic process is one which adapts and flexes according to the
context, the system, and it's architect(s). Much of this organic
nature comes from recognizing that the architect decides which
decisions and elements of the design are architecturally
significant, when it should be addressed, and how (from "thinking it
through"/envisioning it in the mind's eye to "modeling out loud" to
... using a pattern to ... building a paper mock-up or a code
prototype ... to incremental development).
Architecture decisions are those that the architect judges make or
break for the system. They have to do with game shapers and game
changers. With strategic impact. With design excellence and system
integrity. And they may generally be characterized as those have a
high cost of change, but it is, I believe, important to highlight
those that have to do with the strategic (impacts competitiveness)
approach. If we set out in the wrong direction that will bear a high
cost of change to correct, but chances are good we won't know until
we outright fail. This is because we will get delta feedback on an
expectation set we start to shape and confine according to the
direction we've chosen. These are the big failures of imagination,
of missing the mark.
Why this image, in this context? It's a better (lending more
organismic motion) visual analogy than the traditional cogs that I
used (with some reservation, but I relied on people knowing that our
approach is in no way mechanistic) in Getting Past ‘But’: Finding Opportunity
and Making It Happen, 2008. That paper is about agile architecture.
Here's another image for Getting Past But:
And the longer we take trying to get it right, the higher the cost
of being wrong!
It doesn't do to rub our hands in self-congratulation if we're
"doing agile" but merely delta incrementing our way to a entirely
wrong solution for the market. If we don't explore just enough before we get resources and egos vested in a solution concept,
the tack we start down (whether waterfall or agile) becomes largely
self-confirming--for those involved. The product manager. Beta
My family is collecting a set of mis-spokes -- mine.
Ok, so you know Dana talks with his hands.
And eye contact. Even when he's driving. One day I
blurted out: "Keep your eyes on the wheel and your hands on the
road." Fortunately he is a superb driver, even when
Seeing a mule deer in Bryce Canyon that my family hadn't spotted, I
exclaimed "There's a there's a!" A few days later, playing
20 questions, Ryan with obvious impishness said "Oh, I've got one." and Sara said "Is it
bigger than a microwave" and Ryan said "Yes!" and right off, without
a moment's hesitation cued only by Ryan's demeanor, Sara said 'Is it a 'there's a"?' and Ryan said
"Yes!!" in a gleeful tone. Ever since, a deer of any sort has been
known as a there's a. It has spread to my kid's friends. In time, who
knows, you'll be calling them there's a's too--though unlike other
people, you'll know why!
Tonight, in gentle earnestness I said "Please don't talk with your
mouth open"--meaning full of food, but my family was totally onto
that and immediately started the "there's a there's a" and "keep
your eyes on the wheel and your hands on the road" refrain.
But, as much as people misunderestimate me too, I've got nothing on
former President George W. Bush.
my Quixotic submission to SATURN didn't fly. Naturally I half-expected that,
and perhaps it wasn't fair to make the tutorial team choose or
reject so playfully Quixotic a proposal.
But think about it: The art at the technical heart of architecting
that makes it come pulsing to life. Wouldn't that be a great
tutorial? The art that we engineering types put in boxes, but we
mean so much more than boxes! Yet how do we draw what we mean when
the medium we construct with is itself so abstract? So we draw
boxes, and use something akin to what artists and poets
use--something akin, that is, to what great engineers, innovators
and inventors use! We use sketches, diagrams, models, schematics and
use, advance on, and shatter precedent. Yes. But more! We use analogy. We use
abstraction. We use compression. We use patterns (drawn with boxes,
leveraging analogy, abstraction, compression,...). We use iteration.
We make meaning. We use conceptualizations to create and to
communicate and these conceptualizations are not wisps of dreams,
even if they begin there. Boxes--itself a metaphor. Boxes and
relationships. Inter-relationships building synergy. By applying
accumulated knowledge and experience and reasoning we make our
designs a matter more of intentionality than mere accident, and
because we have so reasoned, we have the foil upon which to improve
our understanding, as we consciously evaluate our designs under the
stress tests of execution and evolution. Ah, these boxes which may
be easy to underestimate, are so powerful, for they enable us to
visualize what is otherwise hard to render to support reasoning,
communication, recording and improving. They are expressions of
experience, of know-how, translated into new forms which we sketch,
test and improve, and build, test and improve, but to do so we need
to communicate and advocate and impassion. All this the glorious
defining art at the technical heart of architecting!
Look, I know full well you could say that is just my nuanced way of
talking about what architects do anyway! Ah, but the just-so of what
you might call my nuance is re-orienting. A good part of our field
was never enthralled, while another good part became disenthralled,
with visual modeling. Still others in our field have never quite
understood the value of the conceptual architecture. As important as
conceptual models that orient and organize are (whether for a system
or a field of practice), there is more to this--much, much more to
this. Yes, it has to do with drawing boxes and lines and framing
conceptual architecture so that we see its meaning. Drawing. Boxes.
Framing. Meaning. I could go on. But that would be the tutorial.
I am disappointed. If we don't get our heads wrapped around this
now, how do we "architect the future?" So, my heart verily sinks.
Being spirited in a world of leveling forces is hard to sustain.
Life is so much about boxes. About living with stereotypes and
circumscribed roles, and yet managing to transcend them without
losing the good faith of those who need to put trust in you. For a
tutorial about seeing our boxes in a fresh way, I chose to be
playfully unstereotypical in the outline for the proposal. Well,
gosh, I guess that makes me a modern day Don Quixote. Looking just as foolish. In a few centuries someone
may do a leadership movie about me. ;-)
In sum: Tilting at windmills isn't all it's cracked up to be. Those
giants fight back with merciless objectivity! ;-) So, on second
thoughts, don't watch Jim March's video, and do not, do not,
pay attention to me!
Unless you want to put something to rights in the world. In which
case, you are your own kind of "different." [Then, remember that
many great leaders are the greater for the leveling forces they
transcended. Steve Jobs is a case in point. He was fired, but he
came back to prove himself--again.]
As for Dana, that's the first time he has had a tutorial rejected;
he should be more cautious about doing something (about boxes or
anything else) with me! Should, but won't.
As for SATURN, I well know the challenges of creating a balanced
program that will serve its audience well. This has to mean that the tutorial line up is truly
amazing, and that it will be a conference that the audience enjoys
and benefits greatly from. How very exciting!
must have self repairing egos." -- Dana Bredemeyer
decisions but it is about creating designs, and expressing designs. Designs that
bring experience, reasoning, precedent and intentionality to bear so we obtain
desired system outcomes. As I
provocatively said in the tutorial proposal,
we need to get to the point where we insist that we draw these designs. I'm not,
for example, discounting the importance of the decision to use Java versus C#
and the cascade of environmental choices (and subsequent enablement and
constraint) that hinge thereon. This is not about design views or documented decisions. We simply also need clear mechanisms to gain
cognitive traction on designs, because the complexity of our systems and
systems-of-systems predicates that we do. These boxes, the ones we clarify, just
got more important, didn't they? Our designs and the views that render them
encompass many design decisions. Our
models and descriptions explicate, rationalize, contextualize,
defend, advocate, and guide the implementation of architecture decisions. And,
as I noted journaling in 2006:
do this, we also help educate the engineering community, sharing the experiences
that shaped our decisions. Only when we document our reasoning like this, do we
make our knowledge explicit and shareable. Further, it makes us more careful,
because we leave a record that can be assessed and debated.
In Philippe Kruchten's slideset or Grady Booch's frameworks and views paper, for
example, Visual Architecting or VAP is overlooked. But in this slideset titled
architecture documentation in the real world," Markus Volter says of the
"4+1" model "Not too much used in
practice" (slide 70). Well, I conclude it all depends on the slice of the
world you get to see! Really, I think a process should be organic and
highly adapted to the team, their system and their context, which is to say, it
should be "homebrew" with strong begging, borrowing and stealing from neighbors,
friends and trusted advisors!! We learned this with Fusion. Then its the team's
process, whatever they want to call it. Recognizing this, we tried not to
give VAP a name; I've told you already. But we were backed into it. Hence, Visual Architecting or VAP. Fortunately not
ignored by architects! So quite influential. Oh, another point of history.
We first presented our Software Architecture Decision Model outside HP at a
COMDEX conference in about 1997. Our Software Architecture: Central Concerns, Key Decisions paper has been
freely available on (and very extensively downloaded from) the Bredemeyer
website since 2002! Etc. Of course much has evolved, but the cornerstones proved
well-placed and durable. We have foreshadowed much of what has transpired, and I
think the "something about boxes" direction will do so again. ;-) Well, it'll
just have to be the book that lays it on you, won't it?! ;-)
Sometimes the things that feel really bad when
they happen, turn out to be the best thing that could have happened.
Oh, but I should tell you I'm smiling! I might "crash and
burn" 'cos I push limits, but I have a happy tolerance for myself. A sense of
humor that is well accustomed to laughing at oneself is, I find, a very
necessary antidote to the travails a Quixotic adventurer finds herself in. :-)
No boundaries pushed, no boundaries extended.
To paraphrase Marvin Minsky's theory of how the brain thinks, we set goals,
compare the desired state to the current state, create a strategy, and then our
internal critics go to work as we make progress towards the goal, doing the
course correction thing. Now, as you know, I have very active internal critics
(who do a major victory dance all over my ego when someone else, directly or
indirectly, criticizes me).
What makes that work well for me, counterbalancing all that, is that I also
very actively look for and see the good, in the large and the small, in others,
in Nature, in the world we create, and in myself--what I build in myself as I
interact with eagerness and joy with other minds and ideas and the small
and great glories in man and the world.
If we want to create artificial intelligence, we have to figure out how to
create affirmative intelligence. And yes, this goes for people too. Them bots
are catching up, and we need to stay ahead! ;-)
It would be unhealthy to habitually only wear-away at, to always chip and chisel,
even if it is with earnestness to improve what one does and creates as one
struggles to be good and do good, and fulfill one's aspirations. We also need to
habitually build up, affirm and appreciate and be flooded with joy! In part,
directing this inwards, but for the most part directing this outwards. We do, I
believe, truly need to embrace and be happy with our own good qualities for we
build them at great cost of time and attention--critical attention! But if we
only did that, we'd float out of touch on the balloon of our own
self-importance! And seeing the good in others and in the world is a free and
healthy rush of expansive joy. Better than coffee! Well, maybe as good as
coffee. Or chocolate. ;-) We have that fridge magnet, remember, that
says "Chocolate is proof that God wants us to be happy!" Affirmation, or
confirmation, of good within and good in deed and good in our daily experience,
is happy-making too. And I think there could be few epitaph's better than (she
or) "he made people happy!" It would take considerable Quixotic optimism to do
that, to make that part of our personal mission, though, wouldn't it?
Joyful affirmation of our wondrous life in all its dimensionality--and a
sense of humor--go a long way!
In case you're drawing critical conclusions from my
playfully "unboxed" tutorial proposal, I can do "business as usual" too. Like
this overview for a VAP seminar:
seminar, we present our approach to architecting, covering the visual
architecting process and the architecture decision model that provides an
organizing structure for decisions and the models and descriptions that
explicate, rationalize, contextualize, defend, advocate, and guide the
implementation of these decisions. The process provides guidance and directs
attention so that we don't miss crucial aspects of the architecture, but without
being directive and prescriptive. Rather it is organic, in that it adapts to
system and organizational complexity and uncertainty, challenge and risk. The
process is iterative, and a key value is using the cheapest possible artifacts
(even sketches and diagrams) for exploring stakeholder value and addressing
architectural challenge. So we will explore the value of visual modeling, and
building on experience including the use of patterns. We will talk about the key
concerns that architecture addresses, and present fundamental principles of
structural integrity is pivotal. But while our decisions are technical, what
makes them fail or succeed is very often not! Hence a broader concept of design
integrity is embraced so that we realize a minimalist architecture that is good
(technically sound), right (meets stakeholder goals) and successful (is actually
realized and shows value--from early days through delivery through evolution of
I was reading about Rilke yesterday, having stumbled by
an unlikely path on his Letters to a Young Poet. Anyway, it struck me
that this poet was attracted to sculptors, to people who observe closely and
give physical shape and expression to what they see. The bare-faced direct
reality, and the interpreted reality they sculpt into meaning--meaning they make
possible, but with which we interact to make our own sense of it.
It is perhaps flowery and a stretch to relate this to things we design, but
when we embrace that stretch, we embrace the necessity of observing and making
sense of some realm of the human experience and what needs that presents, as
well as the necessity of interpreting what we see and forging a new reality in
our mind and then in the built world.
We tumble through these interactions. For example, give your daughter a Mac, and she wants a
sleek white printer. These cascades are so iconic they are
immortalized in just such a delightful children's story. One thing creates a
space, a need, for another. This isn't a "requirement," it is an interpretation
of a desire. We look across desires, and figure out what need that expresses and
whether there's a viable business in it.
So, you wring your hands in despair at me, and tell me not only is that
"requirements" (read out of the architect's scope or charter) it is in early
conception or ideation. And then I wring my hands in despair too, because these
processes of observing and making sense of the need and an approach to its
solution, applying intuition and emotion, knowledge and analogy, reasoning and
judgment, all these and more come together again and again whenever we are
designing--the experience as perceivable by the user, or the guts that shapes
the experience of various stakeholders (most directly developers now and over
the evolution of the system, but also users and the business, now and into the
future of new/evolving uses and use contexts).
We create with our mind-hands in this field of software. We are like
poet-sculptors. We give thought physical expression. And we run into trouble
when we think this can be done without creating meaning.
What is the meaning of a USB stick? A USB stick? A little utilitarian piece
of hardware with its invisible threads of enabling software. What does meaning
have to do with it? Bear with me a moment, pretty please. Ok, what is the meaning of a USB stick? Compact backup that allows crude
"failover" if your laptop croaks? [Professionals on the road.] Compact
portability between devices not (conveniently) connected? [Kids transferring
homework between home and school.] "A flash memory data storage device integrated
with a USB (Universal Serial Bus) interface," with ever more capacity, cheaper?
[Continued business, and jobs for your team, if you can drive the capacity-cost
curve, leading or at least matching competitors.] Ah, back up a moment--where it is "Kids transferring homework" how do we
refine or add meaning to create distinction? For a geek (like my son), size
matters. Indeed, for many it is a personal stamp in conscribed world where
personality has fewer options for physical expression. Read opportunity. Now a
"dove of peace" or "save the planet" becomes more important than company logo on
the scant space the compact stick affords! You just transferred pressure to
out-compete in the neck-and-neck race of bigger-cheaper to the skin of the thing
for a chunk of the market. This is marketing? No, this is design and marketing
plays a crucial role. As does manufacturing. But what I'm getting at here is
that this is about meaning and it is about the interaction between guts and
skin. This is moving stuff into and out of, across the boundaries--something you
can only do if you see architecture (or strategic design decisions; at this
level system design not software) as something that crosses boundaries. And,
yes, at this boundary it interacts with marketing. Because meaning is not what
we tell the market (though we can impact perception), it is about what
interpretations and sense and uses we afford, what we allow the system to be
open to. This is design, and skin and guts factor.
When we design mechanisms, we're doing conceptually the same thing. We're
observing and discovering the need for the mechanism, we're using imagination
and experience, including analogy to draw experience from another quarter, to
create something meaningful. Important and valuable, yes. But also imbued with
meaning that we can communicate--this does this, by this means and this is why
it is meaningful to the system. Now at this boundary we're interacting with
developers because as soon as we consolidate how something (addressing a
cross-cutting concern, or delivering a capability) is accomplished in the system
into a mechanism we impact how developers work. Architecture is about
working across boundaries, which means across "turfs" and this means treading
softly on people's dreams and egos but also inviting them to build dreams and
What is important to understand, though, is that we are making the meaning.
Up and down the system we are making the meaning, and we can translate or
transfer, move around, the associated complexity, challenge and risk. We can
push it outside the system (reduce the scope or make it someone else's
responsibility/opportunity), we can push it into the future (deferring
complexity or building
"technology debt"), we can encapsulate it and shield the rest of the system from
it. We can accommodate it, move it, or ignore it (at risk of peril, and hope we
If we can take pressure off the need to always lead on invention, we can
perhaps be more innovative. Applying others' inventions to create greater value
by carefully designing the meaning, and all it implies, of the system. Take
Apple as a case in point.
System meaning is the source of design themes. Design themes give coherence,
one of the legs, so to speak, of structural integrity. And structural integrity
is intimately interwoven with the broader notion of design integrity--not simply
a component we can split off and deal with separately, without concern for the
interaction between structural integrity and design integrity.
So we get back to the mind-hand interworking, the mind creating meaning the
hand shapes, putting something into the world that is interpreted and interacted
with and imbued with meaning, priming the next round of evolution of
meaning-making and meaning-building.
We had a snow day and Ryan and Sara spent hours tunneling a pile of snow,
imaginatively and by dint of laborious work building a snow fort. When they came
inside to warm up, they saw, to their horror, a neighbor's child and his friend
jumping forcefully and vigorously on the roof of their fort.
Some people take pleasure in tearing down dreams. Way too few take pleasure
in seeing them and lending their unadulterated enthusiasm. People who reach and
strive are self-critical. So tread softly on their dreams.
If I have concerns, I try to raise them first to myself taking the other
person's (or team's) point of view. If I still think I have something to offer
to help build the dream but with more resilience thanks to my intervention, I look for
that circumspect path that communicates, through my earnestness and care, my
sense of appreciation and value for the dream and the dreamer. It is not shying
from "putting the source of the bad smell on the table to be dealt with
unequivocally" but rather it is about looking for a way for the team to find the
smell themselves, so their resources and energy can be effectively applied. They
think they did it all themselves. But what of that? I'm not trying to build a
Many definitions of software architecture and system architecture, for that
matter, focus on the structure of the system:
"The software architecture of a system is
the set of structures needed to reason about the system, which comprise software
elements, relations among them, and properties of both."
-- Clements, Paul; Felix Bachmann, Len Bass, David
Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford
(2010). Documenting Software Architectures: Views and Beyond, Second Edition
"Architecture is defined by the recommended
practice as the fundamental organization of a system, embodied in its
components, their relationships to each other and the environment, and the
principles governing its design and evolution."
-- ANSI/IEEE Std 1471-2000, Recommended Practice for
Architectural Description of Software-Intensive Systems
Other characterizations focus on architecture as a set of decisions:
"Software architecture is the set of design
decisions which, if made incorrectly, may cause your project to be canceled."
architecture is design but not all design is architecture. Architecture
represents the significant design decisions that shape a system, where significant is measured by cost of change." -- Grady Booch, blog post, March 2, 2006
Yes, these decisions shape--give form to--the system. But they also
shape--set direction; constrain; bring integrity, consistency and unifying
aesthetic to--the system. And, yes, the structure of the system encompasses
decisions, so there is at least an overlap between these definitions, but the
emphasis is shaded differently. And both are important. How important, we see
when we "unpack" or tease out the definitions or characterizations.
Historical note: we also characterized architecture in terms of a decision
set in our "Less
is More" paper (in IEEE's IT Pro, Sept/Oct 2002). We possibly weren't the first. But
we were early to the game of characterizing "significant" and hence part of the
architecture (decision set).
I jotted the points in the image above, attempting to express the essence of
our view of architecture to an architect; there are little tremors of discontent around the
nature of architecture in the wake of agile and fully empowered self-organizing
teams... Let us focus on complex systems wherewe need to pay design attention to achieving desired system capabilities with intended properties.
This is an important idea that often gets lost--it is one of those "so obvious
it gets hidden in plain sight" notions. We design to bring intentionality to
bear. [It's that Herbert Simon insight: "Everyone designs who devises courses of action aimed at changing existing situations into preferred ones."] In particular, to meet system goals, which are largely expressed in
terms of functions or desired services. Or expressed as capabilities or
features, which I think of in terms of "what" (functions) and "how well"
(properties). Designed, what is more, in the context of constraints and direct
and indirect forces, drivers, points of tension; that is, designed for structural integrity and resilience in the face of dynamic load and the demands of market and system evolution. Designed, therefore, to achieve outward or user-facing and operations-facing qualities (of the system in use/operation) as well as code qualities that determine it's sustainability through adaptation and evolution.
Ok, so if architecture is a set of decisions, but not all decisions, which
ones belong in the architecture? Those that have the highest cost of change
clearly. Clearly? If a decision would cost a lot of resources and time [and
operational downtime or deferral of value (Kris
Meukens) and "emotions and politics" (Doug
Newdick)] to change or revert
and rework, it is strategic. Likewise, if a decision meaningfully reduces the cost of making changes, enabling our business to be more fleet, adapting and extending its services or product set as the market shifts, it is strategic. It impacts our competitiveness. Which sheds light
on the bigger distinguishing characteristic of architectural decisions--they are
strategic. They have high impact. They are crucial to competitiveness,
especially when we take a longer view. Make or break. Game shapers and game
changers. In my blog, back in 2006, I expressed it this way:
The architect of early
generations of HP OpenView said “Architecture is
the translation of business strategy into
technical strategy.” This definition focuses on
the strategic nature of architecture.
What is significant, in this view, is driven by
what is strategic, and what is strategic
determines how we will compete. How we will
differentiate dictates the big things we must
get right, what hard problems we will tackle,
where we will innovate, and where we must be
ahead of competition. And it allows us to accept
good-enough along those dimensions where we are
not trying to create competitive advantage.
What is architecturally significant, then, is decided by the architect (or those wearing an "architect hat"), taking into account business strategy (at the
applicable level of scope); the user, business and development context and the
desires, demands, constraints and forces therein; complexity, challenge and risk; and the cost of
change. This is not to suggest the architect is all-powerful, nor that this is done all upfront. Rather, deciding that
something is architecturally significant means it is one more thing the
architect (or architecture team) is going to need advocate and explain and
defend and influence and coach and tend...nurturing and evolving the design in
the context of organization needs, forces, personalities and more. [See minimalist architecture.] [1/31/13: Strategy, in our view, is not all feed-forward and top-down, but Fractal and Emergent; that is, there is a dynamic dance of intentionality and emergence in both strategy and architecture.]
You could say that the cost of change includes the cost of being wrong, and
this could just as well be wrong about the market (or the feature set we choose
to address the market) as wrong, for example, about a choice of technology that
is threaded inextricably through our system and which may prove to be a bad bet.
So we could bend our interpretation to fit Grady's characterization but I think
that it is well worth the attention shift to go the other way. To highlight the
strategic nature of architecture decisions, and subsume high cost of change
within strategic. Or to tease these out and include strategic, high cost of
change and, for that matter, high complexity (or challenge, uncertainty and
Designing The Defining Structure
But... that's not all. Bear with me for I feel a bit uneasy about leaving
things at "architecture == set of significant decisions" and I'm trying to feel
my way here. Consider this, for example, from wikipedia:
"architecture defines the structure
and/or behavior of a building or any other kind of system that is to be
or has been constructed."
Defining the structure means making choices -- we're going to put this here
and that there, carve things up like so, connect things like so. We're going to
make it resilient like so. Scalable like so. Choices. Decisions. We're identifying demands on the system, the challenges, issues or forces we must contend with, and defining the
structure (comprised of structures) and behaviors (changes in state, interactions among structures, control, etc.) and these impact one another. So we have to make tradeoffs. The structure will convey and conscribe behavior,
behooves us to reason about the behavior (or "how it works") and the implications for the structure
(and vice versa), though our structures may (will!) convey
and enable more behaviors than we define (explicitly in our design). Likewise,
the structures and their interactions give rise to the properties of the system,
and it behooves us to bring experience and analysis to bear on the design to get
more the properties we want. We're designing the mechanisms to address demands on the system, figuring out how to deal with the challenges of these demands and forces like entropy and uncertainties such as those raised by possible failures and changes in the demand landscape -- all within constaints such as cost and important release milestones**. And we're assessing how various approaches contend more or less well with different sets of challenge and uncertainty, altering and amending and redesigning the system structure in that light.
So, yeah, I think architecturally
significant decisions are central and shape and are shaped by the structure, but
the defining structure is a definitive part of architecture--that is, part of
the very identity of architecture. Now this structure, for complex systems, is
composed of structures--the major elements of the system and their
interrelationships and key mechanisms. Mechanisms, again, are composed of
elements that collaborate to some end, to fulfill some purpose like provide a
capability or address (an aspect of) a cross-cutting concern. We may decide to
use an existing mechanism design, generally expressed as a pattern in our field,
or we may articulate our own design in the pattern form, so that the design is
used consistently wherever it is applied, bringing conceptual and structural
integrity (assuming it is a good and proven design) to the system.
Now I say this
because we need to keep in sight our defining purpose. We're giving shape or
form to the system--paying attention to the macro structures and
interrelationships that contribute to the structural integrity and
sustainability of the system, as well as any more granular structures that
contribute to design integrity, providing for consistent approaches or to
address a cross-cutting concern. But the form should deliver and serve the
system function(s) or capabilities, and it should be sustainable (so evolvable and, as
pertinent, scalable, and so forth).
Hence we are, for example, assigning responsibilities to architectural
elements (conceptually, components or chunks of the system). Yes, this is a
decision. But we aren't going to fill out a decision template for each
responsibility we assign. Well, I wouldn't advocate it! That'd be unbearably
onerous to do and to consume! So we are going to chunk up and describe and
rationalize why we cluster the responsibilities the way we're choosing to. And
so each design element is a whole set of (more granular) decisions. And we
document our design, provide a narrative that tells the story of the choices we
made and why they make sense. But the key is the design, drawn as a (set of) model(s)
(visual, symbolic, textual, or a combination), and explained using words and possibly (probably) more models (or
diagrams or sketches or code snips or prototypes).
This design is just one of many possible designs each of which will address
some conjoint set of requirements and forces differently. So a key activity in
design is reasoning about the relative merits of various options that open and
close at different points in this multi-dimensional choice space. There are so
many options we aren't even going to see all of them, but we try to keep a trace
of the thinking and the doors we close (options we decide against) and avenues
we keep open (making assertions about what we expect this means). So all this is
not a matter of decision by decision documenting on a template. There are just
too many. But we try to keep the narrative, the story of our reasoning accurate
and true to our choices and reasoning. This will be invaluable in explaining and
defending and evolving the design. But there will also be choices that are so
subtle we didn't even know we were making them. Life. We do what we can, and
count our blessings for blink intuition. We try to surface the reasoning behind
the designs to communicate it, but we're a step ahead if we have explicit
designs! Every now and then we'll pull out a decision as a big shaping decision
worth documenting in a way that we can pull it out and it is a thing, a
decision. And other decisions we will subsume into a view and describe the
general reasoning behind the choices and highlight the important defining
characteristics of the design and the rationale for those and implications and
such. The context for all the decisions on that view is shared; that saves us
(and our readers) work. Within a design element (like a component) there is
again shared context including shared rationale. Etc. So, what I'm trying to say
is that we have some of each. We have decisions we document formally. And we
have designs that are inherently many choices or decisions, but we document them
not by teasing each one out and trying to give it a systematic full decision
template treatment, but rather in a more aggregate form, in families of
decisions, if you like, as pertinent to the design or element of the design. For
example, we document each component on the conceptual architecture view, listing
its responsibilities and the principles and overall rationale for this
clustering, highlighting what is important to draw out.
So I don't so much care about the language we choose to use here, but I do very
much care about the behavior it causes us to adopt. If we say decision and
decision means document with a template that is a slippery slope to a lot of
documentation. Well-meaning... but as you can see from my journal, a well-meant
pile of words is almost as useless as no words. ;-)
Inherently we're "giving shape to" the system. Principles and values and
other expressions of culture are part of what we use to do this "shaping," this
influencing of the form and the expression, the aesthetics and the properties of
the system. Giving "shape" may not (though for agility/evolvability/adaptability
generally does) mean "modular" but does mean some conceptual structural elements
are being designed--whether we think of behavior in the foreground with
structure in the background (providing the "nouns" if you like) or vice versa.
They may be highly distributed like role-related responsibilities associated
with aspects or cross-cutting concerns. Or consolidated into a modular element.
And where decisions, like which technologies we're going to
use, "give shape" to the system in profound ways (making them costly to change,
but also influencing the very nature of the thing--its significant properties)
these are architectural too. Rats, I just stumbled on another dimension to the
way we characterize architecture, didn't I? ;-) [I write to learn, to
see... and risk being foolish. We add detail ("complify"?) to find the
simple, essential structure ("simplicate"?). The thing about how we characterize
architecture, even if it seems an over-raked turf, is that it orients us -- it
points the direction, sets expectations, even impacts how we feel. If you don't
agree with the last, how does that make you feel? Oh, now you get my point. :-)]
Is/Is Not Architecture
To clarify what something is, it is often useful to consider what it is not. Architecture is often called "high level design" distinguishing it from "detailed design." And architecture is distinguished from "requirements," separating "the what" (what capabilities, or functions and properties, the system will offer) from "the how" (how the capabilities will be built). Rather than "high level design" we prefer to think about architecture as decisions made from the system perspective with system outcomes in mind, and rather than thinking of requirements as some sort of "capture" activity we think of it as part of the design activity that relates to identifying desired system capabilities while architecture deals with designing the structures (elements and relationships) and mechanisms to deliver those capabilities (including system properties, like those that relate to structural integrity and evolvability).
Decisions Made from the System Perspective
We help make "architecturally significant" more clear using
Dana's "umbrella diagrams" (visualizing decision scopes; e.g., system, subsystem or service, and component scopes; or product family, products, features, elements; etc.). Architecture decisions are those that need to be made from the system perspective taking into account their impact on system outcomes. They are decisions that need to be made across the boundaries within the system, and between the system and the environment (hence the "umbrella" or arc across scopes). They have extensive impact, and are of great consequence to system success and viability, integrity, sustainability. For complex systems (where architecture really becomes important), architectural decisions need
to be the responsibility of someone with system purview; if made by someone with limited visibility across the system (i.e., they have local
decision scope/responsibility, perspective into and experience with a piece of the system) they could adversely impact desired outcomes in some crucial way, because they
wouldn't have the perspective, or the local interests of the piece of the system
they're vested in would tend to bias their decision in a way that doesn't best serve
the overall good (impacting the emergent properties of the system, or impacting
other pieces of the system adversely). And they require expertise in system and mechanism design, experience in the domain, and more. ***
Yes, this is cleaving the space in the
way of The Master Butcher in the Taoist story, but really, ask yourself, is
there any other way? There is no recipe, no universal rules, for what is
architecturally significant. Context, experience, and more all factor. There are
places where things seem to just fall into their natural structures and others
where we have to slow down and really pay attention, to find the interstices.
The larger organizing structures are more clearly architectural--at a minimum,
they bear high cost of change. Mechanisms whose impact permeates the system
(from those embedded in a technology choice like an ESB, to those codified in
patterns which also may be inherent in the framework of choice, like MVC in ASP
.NET, to mechanisms we design to address a cross-cutting concern, and more) are
likewise architectural (bear high cost of change, strongly shape the system
lending consistency and integrity--assuming they're well designed and proven).
[Caveat/aside on implications for the architect: All this is not to say that the architect does all this shaping on her or his
own, nor even that she or he makes every architecturally significant decision.
It does mean that the architect leads and is ultimately responsible for the
system design (as intended and as realized) and the architecturally significant
decisions. Thus, for example, when a decision or practice will or is subverting
desired system outcomes, the architect gets to decide (as fits the case, in collaboration with the
team and/or management or with the trust and mandate of the management team), what to do. At
any rate, getting more clear on what architecture is, helps clarify, but
does not dictate who makes the decisions, and who, for example, shapes the
development culture, with its values, mores and practices--though it is worth
recognizing that the culture plays a
significant role in shaping the system and so is a point of architectural
leverage. The more you place value on "servant
leadership" and empowered teams, for example, the more you will want to avoid
casting the architect as one who mandates unilaterally. That said,
while we rely on collaboration in the development teams to define the elements
and interfaces, we rely on the leadership and authority vested in the architect,
and goodwill and good followership of the development teams, to ensure
structural and conceptual integrity of the system, and more broadly, design
excellence. In other words, in the fray of getting things done, the architect is chartered with looking out for structural and design integrity, and while everyone acts with good intentions, what they are paying attention to tends to be local to an area of the system, which may be a feature, service, component, element, whatever. The point is that it is scoped more narrowly than the system, and decisions made at that scope will tend to bias to optimizing at that scope just because that is where the attention is at that point. The architect role is to provide counterbalance, and continuously bring the system perspective to the table when system outcomes are threatened by local decisions. These include "local" in time -- that is decisions that optimize for now, but build debt in defering decisions and work that will have high "interest" or rework/revert/recover costs later.]
Where It Gets (Still More) Murky
Ah... Any characterization of architecture has fuzzy edges for me... Is the
resultant of not making explicit architectural decisions still architecture, or
should intentionality be implicated in the definition? For example, if we eschew
explicit architecture, slipping and sliding into a big ball of mud without
intentional, ongoing, redressment of entropy, we enter the zone of high cost of
change. It has huge architectural consequence, but is big ball of mud an
architectural style or anarchy and chaos? Are shanty towns allowed to
develop as a "pressure release valve" so that the need for no-cost housing for
the utterly poor is given an outlet and these people are kept out of well-to-do
neighborhoods? If so, is this an intentional blind-eye that "serves" the bigger
system? [Of course, those are not my values or preferences!] Are "shanty town" systems similar in some way? Building is a
way of giving shape to a system, raising it from nothing more than an idea to
something that exists in the world (though perhaps pretty much invisible within
a larger system). But if we let this building produce an unstructured mess that
does nothing to serve the quality of life of people who interact intimately with
the system, do we think we have given shape to the system or abdicated our
responsibility to give intentional shape that delivers sustainable value?
Abdicated, that is, our responsibility to make things better through design,
through intentional application of our wherewithal to making things better?
Architecting Across "Requirements" and Architecture
Generally "requirements" (identifying the desired the functions and properties of the system) don't pre-exist just needing to be written down, but instead are part of the design space. Architecture is about form and function, and how we shape the form to achieve
function with system properties that include a span from those that are more aesthetic to
those that have to do with resilience and sustainability. Since the design
space is large, we have to be strategic about our choices. Strategic in how we
approach making choices (which we consider, who does it, when, etc.), and
strategic in the making of the decisions (considering business interests, and
the whole envelope of concerns of customers/users, developers and other internal
stakeholders, and more). The design space includes choices we make about
function and about form, and these interact, and if we separate them, in some
ways we reduce
the design space. That makes things apparently simpler (allowing us to carve up
job responsibilities and stage the design process), but it may raise the cost or
lower the value of the system--may, but how would we know, since we have
artificially and prematurely cleaved the space without sense of context and the
opportunities and challenges it raises?*
Architecture is about system design. So architecture is about the system in
its context, and about parts and their interactions and collaborations giving
rise not just to system capabilities but system properties. This we call
synergy. System properties are emergent from the elements and their interactions. This is not to say they are always and entirely accidental.
We can, applying experience (our own and consolidated in the growing body of
knowledge of our field--for example, in the form of patterns and even tools and
codified in our development environment/infrastructure) and reasoning, bring
intent, or goal-directed purposive design, to bear to ensure the system has more
the properties we desire and less the properties we don't. We're always pushing
the envelope on system designs (else we should not be designing, but rather
choosing someone else's system) so there'll be surprises, but we don't make the
world better without acting intentionally and then entering a cycle of reflect
(how well did we do, did we get what we expected, what did we learn, what should
we try next) and improve.
Well, if architecture wasn't tricky enough, how about the word initiate when used as a noun? Mirriam-Webster.com and Collins have opposite definitions!
Tricksy. Hobbit. Oh, did you see today's xkcd? I
visited with Dana and Ryan during their reading of the Lord of the Rings and it contains some great leadership and life material.
7/26/12: * Just in case that isn't entirely clear, what I said there is a criticism of waterfall! It is noting that we need to design across the design space of system capabilities and user experience and the internal structure of the system iteratively.
1/31/13: ** On the matter of release milestones: software is woven into all manner of systems, some of which have different release constraints than others. Continuous deployment to a pace maker is a different matter than continuous deployment to the heart of Facebook. We want to move more towards continuously deployable, and that too becomes a design force. Thhe design force or constraint being my point. So hopefully no-one gets confused if I focus here on what architecture is, and don't talk about all useful or even "imperative!" practices in the entire software lifecycle from initial conception to decommissioning. Smile!
Complify and simplicate are terms used by Dan North and I first encountered them through one of his talks, but he ascribes them to someone and I didn't catch who. If you know, please tell me the source.
1/31/13: On very useful and much appreciated feedback from Kevlin Henney, I added a clarification: strategy, like architecture, is dynamic -- that is, both intentional and emergent (see The Art of Change: Fractal and Emergent, 2010). This notion is so baked into my thinking about strategy and architecture that I can forget to point it out. The point I was trying to make is that the architect is translating from business terms into technical, clarifying the design envelope and how the system will support differentiating as well as essential system capabilities, etc. Strategy is about setting direction, and shaping direction, and we want our technical direction setting-shaping to fit and enable the business direction.
I hope that it is clear that this was a trace on what architecture is, not how and when the decisions are made. Separation of concerns, and all that. :-)
*** When the team and code base is small, the situation is quite different from when it is large, and complexified by lots of different organizational groups and organizational and cognitive distance, charter differences, etc. In the small, architecture can be treated more organically than in the large, where we need more in the formal organizational structures, communication and process "scaffolding" to support structural integrity and design effectiveness, even excellence.
Words! I was once earnestly and with the best of intentions chastised for
using the word "component" talking about architectural structures. But the word
simply means "an element of something larger," and that something larger sets
the context for interpretation (for example, in conceptual architecture we
obviously don't mean binaries). Well, I don't want to raise artificial barriers
to the way I talk about architecture, so I have tried to shift my language more
to "architectural element" or "element" even though I think component is a
perfectly good word and non-software architects get to use it in ways that make
sense... using it to mean such diverse things as a "component of my vision"
(which translate, often, to a set of features, if you like) to a major assembly
(which might be productized, like components of a
hi-fi), to a discrete part of the system. Our "assemblies" may be designed
around a feature, like a "software
cell," or an internal service that used within composed collaborations to
deliver features. I know it can get contorted for
example in the SOA context, to say a service is a component of a system, and a
service is comprised of components. I do realize that we tend to relate
"component" to parts that collaborate to produce features, rather than parts
that are fairly fledged features. I didn't say full-fledged, because they still
depend on other parts, for example for shared context, and aren't stand-alone
systems (in the Rechtin sense of system). But in general, talking about
architecture in general contexts, requiring a conscribed sense of the word
component seems like wanting hard lines to be drawn where hard lines don't exist
and aren't even necessarily helpful. Can't we accommodate both the innocent
simplicity of "element of something larger" and the more particular meaning, for
example, that UML ascribes?
We want ground under our feet, but hearty rich soil, not sand sifted clean of
all its texture and nuance. That sifted sand has its uses. We can build with it.
But things grow in rich soil. We're talking about a space that spans great
buzzing confusion all the way to professionally designed and soundly engineered
systems. So we need to accommodate organic and mechanistic. Perhaps our language
should too. If we are too pedantically tied to one interpretation, we close off
other options. I try to remember to use element to message that openness. For it
is an openness to interpretation, when we are exploring how to define our
systems, that orients us to new possibility. If I step on definitions people
hold "sacred" they close at least that part of their mind to me. So I have to be
careful, but at the same time an open attitude and goodwill is important on both
sides of a conversation when we are exploring what might be.
It had occurred to me that my post (above) on architecture definitions is an
exercise in navel gazing, and that notion jumped into full sight when I chanced
on and read this:
“How many sociologists does it take to
change a light bulb?”
A: The very suggestion of a light bulb is a
Western hegemonic account requiring emic validation. That is, the light bulb
represents a recursive and socially embedded focal artefact, which cannot be
decontextualized. In fact, its very “existence” points out the localness and
relativity of boundary objects. The light bulb hence is nothing more than a
cultural rhetorical device, scarcely agnostic, and thus surely constructed. The
light bulb then only exists in text and word, and receives its ‘realness’ in
text and word, only.
Paucis Verbis indeed... Well, with so challenging a title as that, I had to
look at something else on the blog to size it up. First stop: Think before you buy -- how's that
image set for illustrating the power of the visual? (Be sure to look all the way
to the end!) Pictures say a lot, don't they?
I have, in various contexts and over the years, expressed my sense that we
build our self, and that our own self is the most important work of
[spirituality,] art and
engineering, of imagination and of practicality, that we build in our lifetime,
for it is of that work that we are enabled to build works in the world (whether
process or product, whether through influence or in constructed stuff, etc.). And we're
discovering that this work we do changes the very structure of our brain [see the inset about cabbies; I'd like to see that study done on software
developers ;-), I mean, think about it--the mental model we hold of complex
software systems has to be every bit as complex as a mental model of London;
wouldn't it be interesting to see ]. It changes our nature in tangible ways. What we do with our
bodies and the very thoughts we have, shapes what we are capable of, but also
builds what we are. A being. Full of becoming.
These two versions--Snow
PatrolVEVO and Grey's
Anatomy Version--of Chasing Cars illustrate the impact of the visual
-- not just using the visual channel, but using the references, the cues, whole
stories that get compressed into visual moments. I haven't seen the TV show, but
that's not required for the moments are quintessential and iconic.
The jaded might say stereotyped or hackneyed, but we don't have to see through
those eyes, now do we? My introductions to a beat off mainstream are via Sara
who gets it through Jazz Dance class, but Chasing Cars came via Sara's harp
recital--one of the older girls in the precollege harp program played (the harp) and sang Chasing Cars with a friend (who accompanied her on guitar). It made me
I'm not usually that soppy, but "before we are too old" sung by teenagers
(as though they really meant it) to
a middle-aged audience of parents was so poignant! My kids are at that point
where they hold the last days of childhood dear. As for us, we're not too old to play
pretend, but other things inevitably pass. At all of these life transitions, if
we're paying attention and notice the passing beyond, it is at least poignant!
In some summers
there is so much fruit,
decide not to reap any more.
Not having reaped
you, oh my days,
my nights, have I
let the slow flames
of your lovely produce fall into ashes?
My nights, my
days, you have borne so much!
All your branches
have retained the gesture
of that long
labor you are rising from:
my days, my
nights. Oh my rustic friends!
I look for what was so good for you.
Oh my lovely,
could some equal
leaves, open your calyx?
Ah, no more fruit! But one last time
as useless as the powers of millenia.
-- Rainer Maria
Rilke, Growing Old, translated by A. Poulin
Rilke died when he'd just turned 51. Isn't that a rallying call? To reap our
days and reap our nights! Before we are too old and bear no more fruit.
[ee cummings poem in time of daffodils(who know is a wonderful poem about life's seasons. ♫This
choral composition sung here by chanticleer is lovely. Naturally I think
that we can take this recursively, with many iterations through the seasons
during the "time of lilac" and "time of rose" of our lives.]
We thoroughly enjoyed Tim Reed's CD release concert tonight, with music from Euphoric Owls (recently released) and songs from Carry Me (soon
to be released). It was, in a word, AWESOME.
I laughed, I cried. In the music, lost and found my self. Really amazing, beautiful ...
words fail me. But... as you well know, not for long. ;-) Ok, I've recovered
enough to share a few. We all loved it. Tim reached across generations and made
everyone feel. Quiet and awed. Smiling tender and smiling warm. Touched
and blessed. What talent he has collected around him; they complement him well.
Ariel was breathtaking!
Ryan came home and headed directly for the piano, inspired to write his own
songs for the album he's recording. Ah dreams. But the thing that is so amazing
about Tim (who is Ryan's voice teacher) is that he treats Ryan as a peer, as
someone he respects and enjoys working with and that makes Ryan just bloom with
the joy of aspiration worth vesting oneself in. So Tim is, you see, talented in
many ways. Being talented not just in playing and composing music and writing songs, but
talented also in working with people, different people in all their remarkable
uniqueness, is gifted indeed. This was clear in his concert, and the
talent he draws out in others serves his talent well, for in each of the quite
different ensembles, Tim's presence was strong--directly, and in what his
perfect foil brings out in those he collaborates with.
I notice people who just laugh easily because they are, frankly,
rare. It is not that they treat life superficially or that life has been easy on
them, but they are fun's ready companion and laughter spills easily from them.
They make us feel good.
In this moment, I can think of only three--of whom Dana and Tim are two.
Martin Luther King led us to a step-change in our
social evolution. As we celebrate what he
accomplished, let's also remember that we haven't
erased our habit of placing people in diminishing
boxes. We still do this by race and gender and more.
habit of scorn, of belittling people, of seeing them
as less than ourselves along lines we impose upon
them, shapes and shrinks our worlds in so many ways.
So on MLK Day, let's break some boxes!
Sara wrote this poem when she was 7 (if you were reading this journal back
then, you may remember it):
A Lullaby You can't Hear
That soothes your heart
Yet you can't hear it
You fall to the rhythm which does not have words or sound
The kind of lullaby that God whistles
A kind that is called peace.
When we listen heart-mind open, as this child did, as a young child can, our
heart-mind knows that it doesn't need others to tell us what is good. We fall to
Not "you fall into rhythm" -- not you fall into line. We fall to the rhythm. The surprise cast of words. We fall to. We yield to.
Peace is without lines. Without aggrandizement. Of self. Of social group. Of
gender. Of age group. Of color. Of belief system. All the ways we elevate
without compassion or heed to what is just.
Let's do something about boxes! Let's rid ourselves of the shams we paste on people we've boxed--those tidy
labels of diminished expectation.
Sara also wrote this playful piece in the same timeframe (when she was 7):
Poems for children
Work is for
Finally getting it
sure you don't fall asleep
Getting more stuff
Dreams are for
Keeping you entertained during
She called it "Poems for Children" but we adults have much to learn from it, do
we not? Compasses (including moral compasses and 97 Things) are for learning how to use them! (Shops are in a loop of selling
to do more buying to do more selling. Work is for
-- finally getting it! Correct. Oh, I finally get it. The child, 7, got
iteration. Persistence. Understanding. I didn't edit her words to say "right"
because "correct" is more correct. It is what we make children strive to
accomplish, is it not? And that burns in a pattern of trying to get things
correct. How partial that is!)
I do hope the child returns to listening to her poetic muses, the kind of lullaby
God whistles, and the face in the window:
A face in the window
is calling your name
Someone calling from the past,
pale from being so old,
only living in your memories
staring from far back in your
A face. Yours? Your father's? The sister of your childhood self? Each of us
has that someone who calls us to be more who we wanted to be when we were
innocent-naive, unbent by the hammering and silting of time. And that is only
one way of reading Sara's poem!!
Did the child mean the poems the ways I read them? Emergence, my dear--(in
reading here) so dear--friend. Poems, like (other) systems, are great for the
emergence they allow as well as the intent with which they were mind-fully
crafted. A child who wrote such poems knows more than we might think, but also
prompts us to think more.
Never underestimate a child. Nor a woman. Nor a man. Nor a person of any color
(those of us who are so-called white people suffer life's formative lessons too). Nor a geek (we
geeks span contradictions too). Nor a Christian. Nor a Muslim. Nor an atheist.
Nor the so-called hearing (we too have to learn to listen with feeling). The
list is long, and if I try to make it more complete, those I leave out are the
more wronged. So simply accept my good intentions and make your own list of
individuals and groups we wrong by expecting less of them because we precast
them with expectations we expect them to live down to.
Ok, back to creating stuff that is useful! See ya!
But. Before I go. Let me just say: XKCD has changed the world hasn't it? My waking thought this morning was: TGIM -- a new XKCD! I searched for TGIM on the xkcd forum thinking that has to be clichéd
yet the only entry is from today! How weird is that?
And with respect to BI, the "ability
to speed the time to insight amid vast amounts of data" puts
visualization at the top of the list of the Five big themes for BI in 2011, by Cindi Howson , InformationWeek, January
More news to boost confidence in a "tech-led economic resurgence":
I liked this blog post titled Learning from Others (teaching us to learn from our own data) by Dan Pritchett on logging production metrics and
visualizing this telemetry. I waited so long for Dan to get back to blogging,
that I didn't notice he had---until I saw that Martin Fowler had blogrolled him
on his redesigned and updated bliki site (it's looking good)!
I think Jim "Cope" Coplien is onto something, though I would probably shade things
differently... and that is part of the point!
Anyway, this is interesting:
"But how could you
get kids who had historically struggled at math — who
had failed prior courses in earlier years — to improve
enough that they could pass Algebra I? What did the data
advise about that?
The answer was
astonishing. What turned out to be the best predictor of
Algebra I success for students who had failed previous
math courses? Success at eighth-grade creative
Why interesting? Problem solving is highly conceptual. Einstein and Feynman
were great because they understood, instinctively, the connection between the
imagination, the ability to "see" with our mind's eye new ways to frame up
problems, to cast them not just afresh but from different angles, to shape and see them and then to solve them. So a
key to designing more complex systems is in good part to develop more
interesting, more varied, more limber ways of repositioning and taking different
perspectives with our mind's eye. No one is discounting the importance of deep technical and domain knowledge, but keeping the part of the brain that is
good at conceptualizing healthily active is important too. And this journal is a
good workout. ;-)
Software design--which is just as integral to writing code as it is to
architectural design--is highly conceptual. As for architecting, varied art
forms come to bear. Storytelling and meaning making among them. Notice how
we, and the community, incline to Grady Booch's awesome paper (improved, even,
with his reading) on systems and failure. This is every bit system engineering
and analysis, yet delivered in a way we readily associate with art and beauty.
Yeah, he's good--like great! But he's good because art and reading have
been part of his life, too. Too.
Leonardo da Vinci was a prolific inventor in good part because he was an
artist. He studied mechanisms actively by drawing them. I read that he copied
the sketchbooks of other artist-inventor-designers, as was a common practice in
his day (you know, that was before Google and Facebook and such). That little
nugget of history contains so many lessons. Drawing. Mechanisms.
Copying/studying precedent. Community of practice. Connections. Innovations. Art
We might say engineering is improved by art, by the keen aesthetic sense yes,
but also by what we learn about making meaning. So, some will dismiss the notion
that art has much place in engineering, while those that embrace it, will have
the kind of advantage Steve Jobs stumbled on, when he found himself drawn to
calligraphy and so to the importance of design--and design not just of the skin
or how it looks, but how it works. One might argue that we cover this base by
including a design class (in the user experience/skin sense) in the software
engineering curriculum, but I intuit that any way that we expand and deepen our
selves will spill into better designs. We'll develop our own distinctive
aesthetic sense which will lend a stamp of uniqueness demarking it from
run-of-the-pack, and we'll develop empathy and imagination, we'll develop other
reference-points from which to draw analogies, etc.
"Google includes a wide range of
personalities, and our designs have personality, too. Text and design elements
are friendly, quirky, and smart – and not boring, close-minded, or arrogant." -- Google User Experience
[Here's an interesting/provocative perspective on education and parenting... Our world will need a great many
people who are very singular experts. And a great many people who can go deep,
yet also make connections, ask new questions, work across boundaries, address
complexity. ... This cartoon reaction is worth a scan.]
Here's a neat example of looking to analogy to find a solution: Fruit Fly Nervous System Provides New Solution To Fundamental Computer
Network Problem. Remember, analogies are not identities, so we don't look for a
one-to-one mapping and throw our hands up in despair at the differences. We look
for ways that the solution (or concept) in another space informs and enables a
solution in ours.
With a minimum of communication and without
advance knowledge of how they are connected with each other, the cells in the
fly's developing nervous system manage to organize themselves so that a small
number of cells serve as leaders that provide direct connections with every
other nerve cell.
Analogical reasoning is immensely powerful! Yes, decomposition into smaller
problems we know how to tackle is powerful too. We need a bunch of tools in our
toolkit, so we don't just hammer something out that works okay-ish... for today... but rather deftly craft sustainable solutions. Looking for proven
solutions to analogous problems so we can translate that solution to our problem
is a strategy. A very useful one.
I thought this distinction from the building architecture space is
Architectural form is
dictated by architectural purposes, such as
the practicalities of spatial organization and control of the flow of occupants.
Architectural form is also concerned with the sense of space a structure
creates, its symbolism and its relationship to its setting”3.
Certainly architectural form can lean
toward sculptural form as in the case where architectural “elements are
exaggerated or when forms reflect a nonefficient use of material just for the
sake of emotional impact”4. But architectural form is always at least
somewhat functional, it is always three dimensional and typically it is client
driven. It must satisfy the needs of the client and the occupants, yet it also
must satisfy artistic and creative goals of the architect. Finally, it needs to
be safe, since it ultimately will be used by people.
Structural form is
dictated by structural needs, primarily to
support gravity and lateral loads, and usually also the need to provide a
building envelope for shelter against the elements. Carefully designed
structural form can exhibit the stark beauty of controlled strength, even to the
point of excitement. Structure can define the visual impact of a building, as in
the case of large exposed columns which give the appearance of strength and
solidity, or the case of tall slender columns which can create an elegant loggia
Structural form is mathematically based, it
seeks the greatest efficiency, economy and elegance that the designer can
create. It is not random, it is not generated by trial and error, it is not
subject to changes in taste or fashion, it is not symbolic of some
3. Saliklis, E.P,
Bauer, M. and Billington, E.S. (2006) “Simplicity, Scale and Surprise:
Evaluating Structural Form”, Accepted and scheduled for publication in the
American Society of Civil Engineering’s Journal of Architectural Engineering.
For some, software architecture is more like structural design and for others
software architecture encompasses both functional or purposive form and
structural design. Where one lands should depend on the nature of the problem in
its context, not on one's own personal preference for taking on only the more
technically challenging aspects of the design (like how to scale). Actually,
scalability is very much about partitioning, which gets us right back to the
interaction between responsibility factoring and distribution boundaries
(or conceptual and execution architecture views). Which is why I don't advocate
cleaving the architect role into "functional architects" and "technical
architects." I do see a great need especially in large IT shops, for creating a
formal structural specialist role (like integration, virtualization and security
specialists) who are resources to architects and their development teams. This
is just a recognition of the deep specialist expertise that needs to be
developed and leveraged across systems that have stringent demands in key areas.
Given the cool Google search
image today, I wanted to see if Jonathan Feinberg (Wordle) had followed my
"suggestion" and created the ability to fill a shape with the words in Wordle... Well, its still a word splat, but
I liked that when I tossed in January's words (so far), the Wordle generated
looks like a fish! How appropriate!
"Just think"! "Make visual"! "Design one architecture"! "Code see"!
"Words need time"...
Eh... Not so fast. Of course I had to ask who has made a word cloud
into shapes--and lo and behold: Tagxedo!
Wow, this month's words make for a mean fish! It might even be better than "The Useless" way to
characterize my journal. ;-)
Tagxedo is the coolest thing since Wordle. When I was writing Wordle comet and Wordle footprint to describe the wordles generated on my site in
July 2009, I wondered how long it would take for someone to do image-shaped
wordclouds. So, Tagxedo went beta in April 2010.
Do look at the gallery!
1/23/11 I think this video stands to be viralled--if you do your
part (ok, so today it has 4,768 views). :-)
Folk meets social-tech commentary. Just
think, what would Woody Guthrie be writing about today/where are our
social alienations now? In what new ways do we make life meaningful
and amplify man's greatest aspirations? And oppress?
Deeply rooted (a)social behaviors (the great, the good, ..., the
bad) amplified on tech... raises an interesting set of issues,
What I meant was when two people see the same thing, and one sees it
as extraordinary and the other as ordinary, imagination and state
are playing a role in the difference in perception. Don Quixote's
willingness to see the extraordinary we may see as addled or as a
gift. And therein lies that same delta (expansive imaginative
interpretation)! I think Jim March's
treatment, his selection of issues to treat in just (over) an hour
and his dealing with them is brilliant!
When I ask architects to think of a leader worth emulating in their
field of experience, they often can't bring someone to mind. And I
think it is so unfortunate that we have such unrealistic
expectations of what an exemplary leader is. So I liked the way Jim
both embraced and debunked those myths we carry around. When we make
leaders out to be once-in-a-generation types of people, how are we
going to see ourselves as leaders, and set out to be great leaders
in our circle of endeavor? We tend to think the issue has to be of
historic proportion, a cause of great human magnitude, and we'd have
to have qualities to match--the oratory skill of a Martin Luther
King, for example. But the need will give us the words. If our cause
is the redesign of a piece of the system, that doesn't demand the
same order of oration as equal rights, but it does demand its share
of persuasion and changing of minds. "I have a dream" is fitted to
the language of our context, and the language we use may be no less
inspiring--just relevant to those we would persuade, influence,
There is so much in Jim's treatment worth commenting on but I'm, you
know, busy meeting deadlines. Still, I can't resist making this
observation, since it also fits this "the delta lies in state and
imagination" notion. When it comes to joy, how many people with
lives as (extra-)ordinary as mine feel they don't have much joy? In
all the have-to of life, the routines, the battles with chaos in
endless chores, how much room is there for joy? And Jim goes right
after that with the first characterization of joy. Joy in
engagement. Joy in putting one's shoulder to that rock--or
piano--and pushing it uphill. Not because that is easy, or
guaranteed by sheer dint of labor, but because the world will be
better if'n we manage to make it so. And it is already better for
the trying. Engagement in something we believe is meaningful is a
source of joy. Joy in the glorious all-out doing of it. Runners
experience it. Thinkers experience it. Lovers experience it. The
body is chemically set up to reward behaviors by which the species
thrives, but the human imagination is perfectly capable of giving
these biological stimulants new meaning that extends their power. Of
course, if we get no joy from our work, it may be that we're doing
the wrong kind of work for our spirit, not following our Bliss. And
maybe we just expect there must be more to joy, so we tuck it away
mislabeled and lose our capacity for joy. Yet as soon as we note
that there is joy in enjoy, we find that joy, beyond
enjoyment, is more our experience. Joy, Bliss. And Glee. Or the
pursuit of our aspirations, connected to where and how we find
meaning, connected to commitment. Or Angels. If you like.
I love how Rilke put this:
"Perhaps all the dragons in our
lives are princesses who are only waiting to see us act, just once,
with beauty and courage. Perhaps everything that frightens us is, in
its deepest essence, something helpless that wants our love."
-- Rainer Maria Rilke, Letter 8, Letters to a Young Poet
Perhaps how we see joy is exactly what limits us from its flood.
Perhaps how we see the leaders in our experience set is exactly what
limits them; we cast them in the shape of the smallness we see. And
we cast ourselves. We need to see others larger, and ourselves
larger. In Jim March's movie, Cory Booker says:
"If we see no angels, it's because we harbor
Cory tells some of the stories that led him to that insight in
possibly the most powerful keynote address I've read; here is one:
'She looks me up and down
and she goes, “You want to help me?” And I go, “Yeah.” She looks me
up and down, and we exchange some more words, and she goes, “Well if
you really want to help me, you have got to follow me first.” I say,
woman pushes past me, closes her door, walks down five flights of stairs, walks
through the lobby of the building, walks through the courtyard, walks onto the
side of the street, walks through some pharmaceutical salesman, at which point I
am standing close to her, and she walks into the middle of the street. Now I am
in the middle of one of the largest boulevards in the neighborhoods in Newark.
She swings around and she goes, “Boy, tell me what you see around you.” I said,
“What?” She goes, “Tell me what you see around you.” I said, “OK. Well, I see
some high rise public housing.” There was an abandoned building that people use
for nefarious things, and I said, “I see that.” And I talked about the graffiti
and just described what I saw around me. She looks at me and shakes her head and
goes, “Boy, you could never ever help me.” And she turns around and storms off.
standing there in the middle of the street thinking to myself, “What the heck
just happened?” So I run after her and I put my hand on the back of this elderly
woman and I say, “Ma’am, what are you talking about?” She whirls around and she
says to me, “You need to understand something boy.” I go, “What?” She says, “The
world you see outside of you is a reflection of what you have inside of you. If
you are one of these people who only sees problems or darkness and despair that
is all there is ever going to be. But, if you are one of those people who see
hope, opportunity, and love, then you can make a change and help me.” She walks
off, leaving me there in the middle of the street.'
You really should read Cory Booker's full address! You know me--I'm
not into imperatives. But Cory's way of telling touching stories to
teach is amazing! And the lessons he teaches in this address
outstrip any book on leadership I've read. And that's saying
Several years ago, I had this image sequence in mind, described it
and Joe Ficko drew it for me, to illustrate this slide. The system
starts small and manageable, but as the system grows in complexity,
if kludginess grows too, it starts to feel oppressively like the
team bears the whole weight of their world on their shoulders. That,
in a nutshell, is the unbearable cost of technical debt.
So, yes, it helps to be clear that when we "seize the moment"
incurring "technical debt" to garner the position of early leader in
a market, we have made an investment we need to pay interest on.
Which is to say, we need to spend explicit cycles refactoring,
recrafting, testing and documenting the system. That said, I do
believe that we can serve our teams even as we "seize the moment" by
applying design thinking (making things intentionally better) from
the get-go. And design thinking must be self-documenting--in drawing
and describing our intentions, we have to think clearly about them,
and we improve the thinking by that process and by exposing it to
other collaborating minds. And self-testing--we have to test our
designs as diligently (though with the [in]formality that fits the
medium) as we test code. Not BDUF, but quick agile cycles learning
with the cheapest design medium that will serve to clarify the "game
shaper and game changer"-level of concerns of "this extraordinary
moment. Yadda yadda.
Never confuse activity with
productivity. It is not what goes in your end of the pipe that
matters, but what comes out the other end. Everything but intense
thought, judgment, and action is infected to some degree with
meaningless activity. Think! Judge! Act! Free others to do the same!
design? What makes something a design problem? It’s
where you stand with a foot in two worlds—the world
of technology and the world of people and human
purposes—and you try to bring the two together."
A very private unknown artist dies. Her obituary is posted and the next day
John Maloof Google's her name, and finds the obituary notice. John
Maloof, two years earlier had acquired a large proportion of her
work, largely in negatives. His interest in, and appreciation for
her work had been slow to take root in him--it was in negatives and
he wasn't a photographer. Isn't that timing something though?
Vivian Maier's work is remarkable. The story she tells in images is touching,
compelling, impressive, ... my mind is too stunned to summon all the
words I know belong here!
Thanks to Daniel Stroe for pointing me to the story and photos
on BBC News and John Maloof's blog. I'm ever indebted to my scouts
and Daniel especially! Well, naturally I had to scout around a bit
myself, to discover more of the story of this woman who visually told the story of a city's people, the story of times a changing. So
stumbled on this:
Westerbeck explains that Maier’s work lacks the level of
irony and wit of some of her Chicago contemporaries, such as Harry Callahan or
Yasuhiro Ishimoto, and unlike them, she herself is often a participant in the
shot. The greatest artists, Westerbeck says, know how to create a distance from
Westerbeck admits that he understands the allure of Maier’s work. “She was a
kind of mysterious figure,” he says. “What’s compelling about her pictures is
the way that they capture the local character of Chicago in the past decades.”
Doesn't that strike you as rather pompous? No wonder she was
private! One of these days we are going to say that there is a form
of art that has been dismissed, I'm sorry to say, too often by so
arrogant a tarring. It is the art of the people, art
that knows and expresses something about what it means to be a
person, and to be a person encountering people. Thank goodness for
men like John Maloof! Really, one has to trust one's instincts, as
Vivian Maier trusted her own. John Maloof has good instincts, and it
is no wonder Maier's work found him!
Well, I am much in love with M C Escher's work, which firmly places
the artist in the art. Escher's Eye, for example, richly
....how I think about deadlines. ;-) Gotta go!
Except... I have to tell you. I have a slide in the second
half of the Making It Visual presentation (that you haven't
seen yet) that is about the detail that is included, and the detail
that is occluded. And Vivian Maier is a master at
choosing the just-so of detail that is a compression rich with
meaning and story. That is a component of what we are going after in
our art of architecture. And while I'm being outspoken, let me say I
believe there is art in
software, including architecture. At least, it is there for those who make it so. Hidden perhaps
to Westerbecks, or hidden without a guide to reveal it and tell its
This was a woman whose passion for her work dominated her life, her
brilliance is astonishing, and Westerbeck is dismissive? Isn't "the greatest artists distance
themselves" just a little too trite to be trotted out just now?
When someone is redefining the rules, stodgy formulaic responses
seem a little out of place. Vivian's work captures spontaneous
unstaged moments, but that doesn't make them less objective. Isn't
it sufficient that an artist distance himself enough that he can become a
fair object of study? How close and yet how distant Escher had to be
from himself, to etch mans reckoning with mortality in his own eye!
That is a lot more distant than someone who has studied himself so
little as to blandish a unique and crystalline vision with some
leveling schoolbook treatment!
Smile. Uh, now I have to go and work out to Marx Brothers so I can
figure out how to make the point I want to make being less unkind to
the person voicing the "designated alternative viewpoint"! ;-)
Then... there's deadlines... and there's Escher's Eye. ;-) And Marx
Brothers. What can compete with that... right now, anyway?
Later: We really have to get over this notion that the artist should
have no part in her art. Life is the greatest artist of all, and we
are each complicit and deeply enmeshed in it--whether we choose to
write "object poetry" or to create an entirely subjective
expression, if we just write what life tells us (in whispers and
gasps, in shouts and cries, in images and tones), we'll be true to
our own art. Frankly, it is audacious and courageous indeed to put
oneself into a work that will be judged--by muggles even. Life is
the greatest artist? Well, what better happy coincidence of paths
than to go from writing this post to watching Duck Soup?
Life's sense of high farce, life's sympathy for our predicament,
Yes, we too put ourselves into our "so impersonal, so objective"
systems. We do, and we should. Back to Escher, this time to Gravity...
I and others, have used it as a visual metaphor for the "big ball of mud" of a
software system, and it is great isn't it--each developer puts her
and himself into the system, and it transmogrifies into its own
emergent form-shifting form...
I am so happy for my scouts. And Ryan (our resident Marx Brothers
fan) is a great one. I've said this
before, but I'm happy to repeat myself--where have I been all my
life? I mean, stochastic processes and dynamic programming are
getting their day in the sun with business analytics and BI... and
perhaps I had to do that, to appreciate Duck Soup... Well,
there's also the small matter of preferring outdoor runs and
rambles... If you have to workout indoors though... video on demand/Duck
Soup is a good way to go.
Tracking down a neat visualization of influence maps, I stumbled by
chance on the cryptoforestry blog--scanning across the sequences on cave
drawings (early visualization of social systems and more durable
recordings of tribal memory--we still have some of the pictures but
not the oral accounts), I was intrigued enough to read into
bits and pieces, rising* to the most recent post on Exploration Fawcett. And was drawn by "he was an acute
observer" to this passage:
"It took me a long time to start reading it. I thought it would be
tedious reading with undertones of obsessiveness and dullness and
the cover didn't help either (and it is a trash book, it does not
mention year of publication). It turns out that Fawcett was a
headstrong but friendly humanitarian with a Victorian mind over
matter and an acute observer. If Indiana Jones was not a film by
Steven Spielberg but a book by Jane Austen this would be like it.
Amidst the atrocities of the rubber boom Fawcett combines a firm
grasp of the situation as a social wrong with a never
wavering sympathy for human frailty. His stance on the Indians,
believing their belligerence overstated, is incredibly modern and
suits him well in his explorations. He is more Ray Mears than Bruce
wavering sympathy for human frailty" is so important,
don't you think? If we are to "harbor angels" we need to have
sympathy for our own frailty, and then it is a deep well of empathy
with others--this, you see, is a great antidote to arrogance. We
must be optimistic and confident we can bring about the change we
see, without being dismissive and self-aggrandizing.
* I like to follow the trail of a person's mind, and blogs are
"up-side-down" ... unless you're visiting regularly with that
So much of our time as architects and developers is spent figuring
out what the system does, with the why's lost to the wash not just
of team attrition but the fallibility of individual memory and the rather
selective nature (and active forgetting) of "tribal memory". Valiant
adventurers looking for lost cities? Indiana Jones seems not so far
off a hero, looked at like that. ;-) And this Fawcett, with his
determined ability to "make his own choices" and survive with his
own adaptations of mind seems an intriguing figure.
This from a Bredemeyer Consulting mailing list signup:
"Love what I've seen so far -
very concise and easy to follow. Thanks!" -- Adrian
Lest all the words and playful thoughtfulness of my journal fool
you, I can do concise, simple, and straight-down-the-line minimalist
action oriented. Here, I dance with angels and wrestle with demons,
complexifying in order that when I simplicate it is knowing that I
did my own form of due diligence.
So tell me, as we hurtle towards the 5th anniversary of this
journal--does it do me more harm than good to share it? I'm
astonished and touched by the "return visits" stat on the dashboard
for this site, but the 1 hit bounce-offs make me wonder if I do
myself a disservice to allow it to be accessible. I do feel sympathy
with Vivian Maier, feeling inclined, in the absence of
encouragement, to want to shield my notes from the kind of disparaging
assessment that a bounce-off signifies. It seems that the
potential for harm is higher than the potential for good; indeed, I
know of no good that it does.
I have been a poor scribe of my adventuring this past week! No, I
wasn't pouting because no-one sent early 5th birthday greetings to
this journal. ;-) While I think this is quite the most exquisite
request for feedback I've encountered:
in the case of my journal, I see the ill in it well enough to
realize that what is thought is better not told!
And yet,... do you think my journal so much less than that of
another adventurer? A Fawcett, for
example? I know. I know. The book. The book. Actually, three. I
think you'll like them. I like the form that's emerged for each, and
that's so critical don't you think? To have the form that invites
filling? Why three? We
need the "hoppers" so one doesn't try to be more than it should...
there'd be more, but we have to focus. ;-)
And this form, this trace of my exploration, my
adventuring-encountering with minds of others is a form I enjoy --
to a fault! -- though it is generative too.
So, do you think we should accept an invitation to write a chapter
for another book, or press myself and Dana into getting these books
It may, for example, come in useful talking about
When I read this:
too, she was obscure and sometimes inscrutable; and though obscurity
is sometimes, in Coleridge's phrase, a compliment to the reader, yet
it is never safe to press this compliment too hard." -- T. W. Higginson
I thought of code--where inscrutable might be taken to be entirely a
compliment to the writer... which called to mind:
"Any fool can write code
that a computer can understand. Good programmers write code that
humans can understand."
-- Martin Fowler
I am looking forward to carving out some hours to read Martin's DSL
Well, the neat thing about architecture is that there is no
confusion: architecture is for humans to understand. Busy humans.
Humans who have to live with it, or its consequences. And therein
lies quite the rub!
Three books. One beautiful little thing that readers of this journal
will, I think, quite love. The Action Guide. And a third more
expansive. The full-featured book, if you like. Top of the product
Over the timeframe of the last Agile conference, I paid attention
(as I do) to the tweet streams of the likes of Martin Fowler and Bob
Martin, and I know there was concern about a preponderant emphasis
on the social/management/teaming aspects of agile and lean, leaving
a yawning gap on the technical side. Well, hello, welcome to our
world! If we are going to "pull up" and go to a conference, it's
going to be to get what's new-new, what's sizzling hot. Leaving Martin and Bob to conclude that agile and lean have been hijacked by those
who pay attention to the project management aspects... Hijacked, or
an indication that it is just time to say agile and lean have moved
into the "mature" phase of life where it's less about creating an
identity and more about settling down to business, taking care of
Craftsmanship Manifesto communicates well what Uncle Bob says it intended to... "We are tired of writing crap." And that is a very sorry state of affairs! Unfortunately it is a
state of affairs that comes of how we set our world up. Crap isn't
what software folk want to write, or set out to write! It is a
symptom. Not a symptom of incompetent people or bad intentions! But a
symptom speaks of a need, an opportunity for a new movement.
Ironically, while we still have very serious technical challenges to address on
the path to great software, there are also very serious
non-technical challenges that have to do with how we set things up.
The path to great is multi-faceted. It has to do with art--with
exploring, making and communicating meaning and beauty. It has to do with
rigorous engineering--codifying, transferring and applying design
knowledge; in our field we mainly do this in the form of patterns--or
the more nuevo so more tech-sexy kata (as it is used in software).
It has to do with craft--with experiential learning and skill that
comes of paying attention as we work ... and contemplating the kōans
of the sage masters of the field... And it has to do with the
teaming, communication, collaboration and work management issues.
The last set will dog the technology issues no matter which new
"camp" they move to, because they are part and parcel of creating
systems when, bother, people have to work with people not just
machines to create something complex.
Software is a vast landscape. It stretches from (yes, love 'em) end
users programming in Excel to kids and hobbyists programming their
Mindstorms robots to apps to enterprise applications to... the good
folk programming the power steering in my car that bails when the
air pressure in my tires falls below a certain point... We need to
embrace this diversity, while at the same time making room to
attract those who want to be "rock stars," who want to be known for
being the superstars of our world -- our craft, sometimes. Our very,
very rigorous engineering discipline, at others.
Again, the software field is a vast landscape. And it needs to be.
Our dependence on software, on this "fabric"
we have draped so pervasively, is so great, our appetite for what
software enables so vast, we can't depend only on a select set of
superstars. We must not (continue to) make it a field that expunges
women and minorities. We must not make it a field that repels gentle
folk who don't want to have to hack it in a competitive arrogant
exclusivist field. Sure, we need to have spaces where that's ok,
because we need the people to whom coder superstardom appeals. We need to
have languages and programming paradigms that are accessible to a
broad base, and we need to have the power languages and paradigms
for systems that demand it. We need to have venues to challenge
ourselves to stretch the limits of software--the aesthetic limits,
the limits of pure beauty, the limits of utility, the limits of our
ability to tackle the most stringent demands on what humans can make
machines do! And we need to have venues where we just plain make
stuff work. Everyday stuff. And extraordinary. And frankly, some of
the most extraordinary stuff being done with software is not being
done in what we recognize as our profession! Mechanical engineers.
Biologists. Musicians. Artists. People are using software--they
write--to expand their intellectual and biomechanical reach in all
kinds of domains, and while they write code, their identity is other
than software developer.
That makes software rather unique. So, one way of looking at the
energy the conversation has generated, is to say "yay us!"
Craftsmanship is important. The art is important. The utility is
important. Delighting users--important. Not creating shoddy
stuff--important. All these different dimensions are important. Some
more important, depending on context. The context may be individual
need to excel. I say "amen to that." The context may be software
that just has to fly, no matter what. Many contexts. Driving many
I work very much at the cusp between the technical and the
social/interpersonal and the business so this "working at and across
boundaries" shows up in everything I do and while I try to get
enough clarity to find the lines in a master butcher
(Cook Ting) kind of way, this is a complex world full of
interactions. We look for the lines between yin and yang, but we
also need to recognize that these make wholes. Not holes.
As holes--rat holes--go... here's my 2c: certification of the kind
that costs a lot, creates a class system that is about money (big
corporate money) more than ability. Again, I come back to the span
of contexts in which great and sometimes shoddy but still
utilitarian software is being written. I'd hate to see this
diversity, ingenuity, and spectrum of players curtailed. On the one
hand, I don't think it could be. And on the other, I've lived with
the ways our field tries to expunge diversity and create a uniform
troupe of superheroes. And trying to raise the barriers to
entry is just one way we'd be trying to make it an exclusive
province. Pure arrogance and dismissiveness is another. We've done
enough damage simply with the latter.
So let's have our technical conversations, and drive the frontiers
and the state of our practice. And let's have places where those who
want to hang their hat of allegiance can do so. But don't let's try
to foist uniform bars on our field, nor foster the notion that as a
field, as a whole, we are about elitism. That's not healthy for a
field where "waves of creative destruction" emerge from college dorm
rooms to reshape the competitive landscape. Where moms write code
with their kids to show them an underpinning of the future. And countless
million other scenarios!
...American on Purpose, the autobiographical story of Scotsman turned
American comedian and late night talk show host Craig Ferguson. In the preface
Little League had taught my
son that failure is not
disgrace. It's just a pitch that you missed, and you'd better get ready for the
next. My son and I are
prepare for glory by failing until we don’t.
I watched Howl's Moving Castle with Sara last night. Hayao
Miyazaki is a genius at wrapping his penetrating message in anime
that is as unlimited as the imagination and is at once full of the
magic of childhood and yet deeply profound so that as one "swims in"
the contemplation it invites, one finds still more gems of insight.
A girl is transformed by a spell into an old woman, and this all by
itself is full of on-the-face-of-it and beneath the surface insight.
Her orientation to seeing the bright side is her blessing.
We prepare for glory
by failing until we don’t. But we do so with a kindness
towards ourselves. We may call it failing or, more positively, call
it trying, exploring... Though sometimes it can feel like there is
no better word than failing. Trying to get the organization to
"repay technical debt," to rationalize the code base to provide a
better platform for product derivatives, to explore an innovative
product idea--anything that requires convincing and direction
setting through persuasion rather than control over budget, can feel
like a Sisyphusian path, or at least one beset with setbacks and
obstacles that consume us seeming pointlessly. All the travails of
architecting. Yet, don't we at least mostly enjoy the endeavor? If
we are playful and joyful, resourceful and resilient, the trying is
Seeing the positive is not a vacant attitude we ought to scorn and
It is puerile to assume that
people who seek out the positive are superficial careless thinkers,
or servile flatterers! I would no more assume a dark and curmudgeonly
person to be a shallow fickle creature than a joyful optimist!
Optimism is a state of mind that, in a world where hurt and darkness co-exists with joy and light, is no easy
achievement! -- moi, 3/30/10
The protagonist of Howl's Moving Castle redeemed first
herself by this ability to see the good even in desperate
circumstances, and then she redeemed those she loved--because though
she saw them clearly as they were, she also saw them as their best
selves and loved them for the greatness she saw. That was her gift.
Her talent, and what she gave of herself.
We are each complex bundles of lesser and greater qualities, of
foible and glory. We are finite beings, with finite time to create
ourselves, and build our products and livelihood and manage all that
has to be managed, coped with, and achieved. Love tenderly embraces
the frailty without derision, and exults, celebrates and adores the
Still... we all suffer our humanity. The more we extend it, the more
vulnerable. On Friday, Sara exasperatedly said to me "why do you say
so much that no-one pays attention to?" It was one of those moments
where a spot of temper shines a glaring light, but little does she
know the full (vast) extent of it... ;-)
"I am quite aware --
that in a setting filled with faculty, friends, and parents -- the
supply of free, unsolicited advice already far exceeds any demand
for it." -- James March, University of Alberta
Convocation address, 2009
In our Architect Competency Framework (2002), we have only one band for
technical, but this is a band that distinguishes the architect from
an already experienced developer or technical specialist. This
technical foundation is expressed in the "level 1" technical skillsets. To be very clear, it
assumes depth of experience in the technical area that is a
foundation--a foundation gained in advance of becoming, and
sustained and built upon in order to continue to be, an architect. [If we
were to try to create a program that "out of the college box"
produces architects, the founding assumption set would be entirely
different! We would have to create internships and an extended
academic program, much like building architecture and medicine. I
just don't see 4 years of undergraduate class work and the size of
projects that can be woven into that context being enough.] That
said, in the technical competency elaboration, I probably need to
say more, for example, than "Designs
mechanisms to address cross-cutting system concerns." That is
a great big bucket of responsibility with competency implications
right there, and deserves to be elaborated! :-)
Even so, what we were doing in 2002 (actually the origins of that competency framework was
created for a class to help managers understand how to support and grow their
architects back in 1999), was creating awareness that the soft skills are
important to creating not just good, that is technically sound architectures,
but architectures that are right (meet the conjoint set of stakeholder needs in
ways that are differentiated and economically, technically and organizationally
viable and sustainable), and successful (actually delivers that value). Now, 10
years (give or take a year or two, depending on how you want to count) later, that is
not a done deal. There is a perennial thrust to reclaim "architect" as an
entirely technical role, one that focuses on the toughest technical challenges
and forget the business and soft skills fluff except in so far as it is needed
to get a technical solution adopted without (quite so much) demur. Those who
want "soft skills" to sugar coat a technology pill that the organization is
balking at swallowing, are coming at this from the angle of technology push. The
whole point of the competency framework is that while sometimes technology push
is exactly the right thing to do, it is from an understanding of the business
and customers that a strategy is developed. A strategy that may be technology
pull, or technology push, or some of each.
When I'm working with architects on interpersonal effectiveness, I raise the
question of ethics. Working with some virtualization "architects" (the technical
specialist kind), I used the Derren Brown "red BMX" clip as a prompt for that ethics discussion. One of the architects, in absolute
earnestness, asked why we don't just use Derren Brown's techniques to make
customers want the solution we've decided on. Doesn't he have a point? I mean,
look how happy the guy is with the BMX bike! Wouldn't that make everything just
so much simpler? We get to decide what we want to do. Then we spend a few
minutes with the stakeholder, and they're ecstatic with what we put in the box.
Well, if you don't see the fallacies in all that, do I have a journal for you to
read! In short, yes, we do want to make stakeholders happy--even that kind
of kid-bouncy excited happy. But we want to do so authentically, and with a
solution that works in its intended context. In other words, there's just a bit
more to be done up front, and along the way, to understand the forces that
impinge on the problem-solution. There's somewhat more to be done to creatively
and imaginatively, and by bringing experience and expertise and codified
knowledge and reasoning to bear, come up with a characterization of capabilities
and solution design. Uh, right. All the useless stuff I explore in this
journal, that you don't need me to rehash. But also more. So much more.
In short, the architect competency framework needs to be understood to be one
that assumes even entry level architects have a strong grounding in technical
skills. It focuses on what, beyond the skills gained in the first
several years of the technical career, does an architect need to know, do and
be. (This is obviously different for a Business Architect, who instead
needs to have a strong grounding in key areas of the business, developing depth
of knowledge and the kind of blink insight that is born of experience, and
developing business cred.)
The neat thing about this journal format is that each month starts with a
clean slate, and a chance to try something new. To fail, if you like, in a new
way. So the end of the month is a chance to review the failures to date, and
consider what tack to take in the month ahead. Oh yeah, theoretically there's
the archives, but ... the
current month is already more than enough to fry attention circuits! :-)
Well, that's if we continue to have power through the ice storm over the
next two days...
2/1/11 so far so good... the ice is really pretty. When a bird settles on a
branch, the tree chimes! Beautiful, but with an edge of foreboding in a world
highly dependent on electricity and all the tech it gives life to! The worst of the storm, with lots more
freezing rain and high winds, is supposed to hit this afternoon...
I can be reached
. 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! Bring value, and I commit to using what you teach me, to convey it
as best I can, help your lessons reach as far as I can spread them. I try to do
this ethically, giving you credit whenever I can, but protecting confidentiality
as a first priority.
Restrictions on Use:
All original material (writing, photos, sketches) created by Ruth Malan on this
page is copyrighted by Ruth Malan. All sketches by Sara B. are used with her
permission. 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.