If you haven't watched
Gandhi
in a while, I heartily
recommend it! It is about a great leader, and about
great followers. And it is about principles with catchy
names like "An eye for an eye makes the whole world
blind." Deep, nation-changing principles. Would that we,
the world, would rise to Gandhi's vision the way the
Indian people rose to it. How can we be so jaded, have
such low expectations of ourselves and of humanity, when
such a man, and such a people, showed what can be done
with love? The love of a man for his nation (and
humanity), and the love of a nation for that man,
changed the course of history. Love. Not wishy-washy ooshy-gooshy stuff. Tough choices. Firmness and
resilience in the face of adversity. Love, and
gentleness that is not weakness but a force for change.
Shame on us for not demanding that in our leaders!
[Note: If you're thinking of buying the movie Gandhi,
DeepDiscount has a 25% off sale—use SUPERSALE as
the promo code. There, now you can't say you never
learned anything of value from me! Grin.]
11/10/08 Silicon Gobbles Jobs
"Carnegie Mellon
University computer science professor Luis von Ahn has
developed digitization software that could put the New
York Times' entire archive, which dates back to 1851,
online by late 2009. The newspaper has been using
typists to digitize its archive, and in 10 years they
have been able to digitize 27 years of articles. Von
Ahn's software will process 129 years in less than 24
months."
Profile: Luis von Ahn, by Jessie Scanlon,
Jessie, BusinessWeek 11/03/08
Has anyone counted the number of jobs that technology
has transferred not offshore, but to silicon? If someone
does, could we be the new bogeyman? Technology creates
jobs, but also transfers jobs where they can be done
more cost-effectively—to computers. Raising
productivity and reducing labor costs makes companies
more efficient, and more globally competitive.
Rather
than chasing job-loss-causing bogeymen, doesn't it make
a lot more sense to focus our energy on creating jobs to
harness our inventiveness to reduce our impact on the planet?
This is more than re-orienting ourselves so we meet Al
Gore's call to energy independence by 2018. This is
about reducing our impact in other areas too. So, along
the lines of "green IT" and green products, here are a
few books I've targeted for consideration in my book
purchase/reading budget:
-
Cradle
to Cradle: Remaking the Way We Make Things by
William McDonough and Michael Braungart
-
Green
to Gold: How Smart Companies Use Environmental
Strategy to Innovate, Create Value, and Build
Competitive Advantage by Daniel C. Esty and
Andrew S. Winston
11/10/8 Goodreads.com ... and
then some
If
you create a software architects group on
goodreads.com,
please do invite me to join it! If you don't, maybe I'll
get around to it one of these days. If you're new to
goodreads,
this list (by a systems architect) may inspire you.
Goodreads.com gets advertising dollar and referral fees
from Amazon, but they also send readers to B&N, etc., so
it doesn't have single vendor lock-in.
Of
course, Amazon has fired up a social networking reading
group engine, and hooked up with LinkedIn—this will be
one to watch! See, for example,
Rishi Khullar's reading list on LinkedIn. LinkedIn is really
getting cooking! It is exciting to watch!
Lots
of ways to find out about books.
It'll be interesting to see where these two go from
here. Amazon is the next Microsoft and Walmart combined!
Smart company. But an oligopoly in the making...
11/11/08
Software
Architecture Workshop Group on LinkedIn
During the last open enrollment workshop (a few weeks
ago), a LinkedIn Group was created for Bredemeyer
Software Architecture Workshop "alumni" (thanks Salman).
If you are an "alum," it would be great if
you'd join the group. I am responsible for vetting
all requests to join, so it would be helpful (but not
essential) if you could let me know which workshop you
attended (company for an internal workshop, or
date/location for an open enrollment workshop).
11/11/08 Google Trends
I
tried out Google Trends. This is better than
stringing paperclips!
First I tried "software
architecture" — a steady decline in searches on
"software architecture" from 2004 to now. The USA ranks
7th on searches on that term. India is 1st.
Iran and Pakistan, and Australia
and Singapore, show up above the USA. Hmmm...
So I
tried "software
architect" — again, a steady decline in searches
since 2004. India is 1st again.
South Africa is 2nd. New Zealand is 3rd. The
Netherlands is 4th. The USA is 5th!! (These are all
countries we've done work in. Grin.)
Now
that's all pretty surprising. How about
SOA? India is not in the top spot. The Netherlands
is! The USA is in 9th. Search volume went up through
2006/7 and has been declining. News reference volume has
been steadily increasing.
Alrighty, "service
oriented architecture"? Increasing in 2004/5, but
steadily declining from 2006. Search volume rank order:
India 1st, Netherlands 2nd, Singapore 3rd, and the USA
4th.News references, on the whole, steadily increasing.
Rats, we're not looking so good! How about "IT
architecture"? 1. India, 2.
South Africa, 3. Singapore,
4. Australia, 5. Malaysia, 6. Ireland, 7. New Zealand,
8. United States...
What about something topical like "cloud
computing"? 1. India, 2. South Korea, 3.
Singapore, 4. Taiwan, 5. United States
Now
for another big one—innovation:
decreasing in search volume from 2004, but steadily
increasing in news volume. Rank order:
1. Singapore, 2. Denmark, 3.
South Africa, 4. India, 5. Malaysia, 6.
Australia, 7. Ireland, 8. Norway, 9. United Kingdom, 10.
Canada
What
do you notice? The USA is nowhere in
sight! What does that tell us? We're so into innovation,
we're past the simple searches to more detailed searches
like "malan innovation"???? (grin)
"Agile development," "scrum software," "6 sigma"
and "six sigma," "agility," ... no search term with USA
ranked 1st. In desperation, I tried "Obama" and hooray,
United States ranks first in searches on Obama. Those
folk in The Netherlands must spend their lives on Google
though, because they again showed up in the top ten!
Grin. And "bailout"? Yep, the USA is in 1st place...
Ok
Google, listen up: what about the meta-trends here? Like,
who searches the most? And who searches high tech topics
the most? As a nation, and per capita? Singapore and The
Netherlands must be way up there when adjusted for
population. And India—what an advantage over China to
be a free country!
So,
what about tech websites? India is first and the USA
second on visitors to hibernate.org, springframework.org,
jboss.org, jboss.com, theserverside.com,
javaranch.com, etc. But the USA tops India on
RubyOnRails.com and .org.
Wahoo! This is better than the
Olympics!!!
Ok,
now for something interesting: try "software
architecture, agile development." It's all over for
us architects! Even
Dilbert's PHB is into agile ...
And
"enterprise
architecture, innovation"... hmmm...
11/12/08 Feedback on Getting Past "But"
When
a core group of architects I respect read the draft of
our Cutter executive report, each came back with
different places to cut, to help me get it reduced to
the Cutter maximum word count. Now cutting 1200 words
out of the report was a hard call—one I wasn't able to
make, so the suggestions were focused on helping me make
a deep cut.
Anyway, one found the circles of innovation model most
useful, one suggested cutting my debrief of the lessons
from
The Wheel, and another the second half of
the report. No-one suggested cutting the story, which
enthralled and amazed me, for that was where I felt most
vulnerable. (I'm sure there are people out there who
think I'm nuts for including it, but they aren't in my
inner circle of architects. Grin.) At any rate, this
gave me an early indication that different people were
going to get more and less value out of different parts
of the report. One of the architects who's just read the
Getting Past "But" paper, came back with some
feedback which I have to share because I think it is
likely to be a reaction that many in the audience will
identify with:
"The content is
very topical. The challenge we always have is how do we
get new ideas/initiatives/products off the ground when
110% of our people (&budget) is on maintaining and
releasing version n+1 of our existing products? As you
can imagine in a large company, there are strong
functional separations (Product Management, Product
Engineering, System Engineering), and even strong
demarcation of roles within a function (Application
Architect, Business Analyst, User Experience, Project
Manager). Metrics, "accountability", and natural group
behaviour all tend to lead us to try and optimise the
performance of each function, or role ("well I did my
job on time..."). We don't lack ideas. Our challenge is
to execute in a "circles of innovation" model. There are
some good and inspirational ideas in your paper; I will
certainly share with the team and beyond."
personal email,
11/12/08
I was struck by the "we don't lack ideas" message. This
is so true in software engineering. We really are an
innovative bunch, though reigned in with the focus on
rev n+1. Christensen talks about the focus of resources
on sustaining innovation (rev n+1) in The Innovator's
Dilemma, though he leaves more there to go after.
And I didn't have space in the report to explore every
topic I had outlined, so tabled that for "the book." I
was planning to talk about the Google model (20% time on
pet projects produces 50% of innovations), and the
organizational implications for innovation that the
executive team needs to take into account. It's too bad,
because the lack of attention in this area in the report
could be construed as putting the onus on architects to
do all the getting past but. Of course, I
did already mention that the report is "smuggling
donkeys" or a Pauschian "head
fake."
It is also worth bearing in mind that every 3-6 years or
so, organizations get to the point where the n+1
approach is just so hard that the platform has to be
refreshed. The technologies it was built on are
outdated, the architecture has devolved to the point
where not only is it slower to add features, doing so is
more error-prone, and when it breaks there are only a
few key people who can sort it out, and so forth (like,
the code base gets so big it brings the dev tools to
their knees). So the opportunity for industry reshaping
innovation doesn't just come around once, when the
product is first created. A good hard look at
differentiating in the next 3-6 years has to be the
focus of any platform "regeneration" effort. And, sadly,
this is often not the case. Simply cleaning up the
current system is a big job, given the complexity of the
feature set by this point in the product family
evolution. That makes it especially important to get the
hub of innovation "smokin" on where the market and
technology and value network is headed, and where the
big opportunities to differentiate will lie over the
next horizon of competition. The ties to the past are
going to be put to the test by your next big competitor
if you don't put them to the test yourself!
Still, in the paper we weren't just addressing industry
reshaping innovation. Innovations also come from
recasting products given a better understanding of a
particular market, a new capability, and so on. In other
words, they may be innovations from within the industry
mainstream, not from a start-up with a radical new idea.
Release n+1 may serve only to introduce sustaining
innovations, but it still makes sense to treat them as
innovations, and organize accordingly! The
size of "+1" increments (bug fixes? a feature
enhancement? a new geography? ... or a new capability?)
is a factor (I don't need a full multi-functional
innovation team to do a bug fix release). Always
focusing on what's just in front of your nose, never
let's you see what's a few feet out, let alone what's
coming round the corner at you... I'm all for agile. But
I think agile needs a pragmatic amount of foresight, or
there'll be more stumbling over than nimbly jumping the
hurdles that come our way. This is a simple as a Dewey
decimal scheme for releases, with longer range planning
for n. releases than .n releases.
So, if we write the book (should we write the
book???), I'd like to think about a set of "but"
arguments and use them to motivate various discussion
and process/techniques/tools areas... As you can see,
"[but] we are too focused on n+1," gave rise to
3 paragraphs, and each of those deserves at least a
section, if not a chapter. The neat thing that The
Wheel teaches, is to wonder why. We hit that thing
that just is so in our context, and we wonder
why, and all of a sudden we're able to see a way past
the glass wall that was reflecting our own constructed
reality back at us.
Now I have to say that the first time I pointed out
"but," the architects in question really went after
their challenge head on and showed what can be done when
you get in front of a problem and lead—with social
grace and goodwill. I do have a nagging concern though,
that "but" will put some architects on the defensive. I
totally don't mean to make architects feel
uncomfortable. Changing the outcome means changing the
context, and as leaders, we need to figure out what in
the context needs to change, and then lead. Sometimes,
though, the context is just too hostile. The "but" we
have to get around is just too tall and too wide.
11/13/08 Featuring Getting Past
"But"
Cutter is featuring our
Getting Past "But" report on
their
homepage (bottom of the page under "Sample our
Research")! That is a wonderful implied compliment.
I
looked around a bit on Cutter's "sample our research"
pages, and this struck me:
"Col. Boyd... has
become known as one of the most innovative minds in the
US military. He was the father of modern maneuver
warfare and the inventor of aircraft design principles
that have changed the way modern fighters are conceived
and built. Boyd countered the "technology for
technology's sake" approach that crippled US combat
readiness with his tradeoff analysis, which helped blend
various design concepts, technologies, and solutions
into constructions optimized for combat agility and
effectiveness."
Borys
Stokalski,
Innovation: The Great Differentiator
Col.
Boyd had just surfaced on Lane's
goodreads.com list I referenced the other day. When
serendipities like that add up, I suppose I ought to
read it. I never played with toy airplanes, so I guess I
need to balance myself out with some lessons in
leadership from the cockpit and beyond.
11/13/08
Software Architecture Workshop Group on
LinkedIn
The Bredemeyer Software Architecture
Workshop "alumni" group on LinkedIn is growing quickly and it
has a truly remarkable member list, including a good many of the
talented architects who have taught me (being that the workshop
is designedly a crucible for peer development). Of course, if I was smarter I'd have learned still more
from them, so don't take me as evidence of how much you can
learn from being part of this group!
All that's needed now, is some of the kind of lively experience
sharing we've had during the workshops! If you are a
workshop alum, we'd love it if
you'd join the group and help make it a meaningful and
useful place to share architecting know-how, and know-what,
-why, -when, -who, and... -what else and -what if!
11/15/08
Erratum
I didn't expect the copy editors to change wording
in my diagrams in our executive report so I didn't look
carefully at them. There's an error in the first circle of both
the roadmap on page 2 and the summary on page 22, which now says
"Innovation Technology, Sources" instead of "Innovation
Sources." If you can't figure out what I meant by "Innovation
Technology, Sources," that would explain it! The correct summary
diagram is
here
(the roadmap just has the bullets stripped off). If you still
don't know what I meant... well, the circles of innovation model
section is what is being summarized in that "wheel" on the
roadmap and summary.
11/17/07 Book Recommendations
11/17/08 The Value of "And" Thinking
Our field
is inclined to either-or polarities. Our systems are
increasingly complex, and we so want remedies to the
"software problem" that the attraction to the "cure du jour"
is strong—so we've seen OOP, design, components, SOA,
agile, etc., create a wave of excitement and then settle
into the state of practice. Meanwhile "waterfall development"
has taken a dunking in the past several years, and the
antipathy has hit the mainstream. Now, it is true that even
today, even ~15 years after I was first aware of the term
analysis-paralysis being used on projects, we still fall
foul of the analysis trap on some projects, not getting out
of requirements and architecture for months and months.
Generally there's some bigger thing going on, like a poorly
defined mission, or high
ambitions on the part of diverse stakeholders creating
conflicts in direction, and there's a
danger of much wheel-spinning and little traction when
trying to bring unity across factions. The lore that forms
around these projects creates antibodies to requirements and
architecture, creating a fertile ground for the next great
new thing promising that architectures can just be grown
organically, self-tuning around market forces and shifts in
the competitive landscape...
So, what are we to do?
The Opposable Mind suggests "and thinking,"
integrating what is necessary to success from all the body
of experience in requirements analysis, intentional and
emergent architectures, design patterns, incremental and
iterative development, pair programming, test-driven
development, and so on. Let's take a case in point: platform
development. There is a lot of evidence to support the value
of product family platform-driven development (think Honda
platform, not OS). Product family platforms by their nature
don't have "a customer," and so there is real work to
be done understanding the market segments, and the
commonality and essential uniqueness across
customers/markets. Not that this analysis should produce
paralysis! Iterative and incremental, emergent and
intentional, these need to come into play early, using
Pareto tools to find the difference that makes the
difference quickly and cheaply, and find which path we
should pursue as we ramp up agile development.
What do I
mean by "emergent" and "intentional"? Well, intentional is
when we design to meet our (known and prioritized)
requirements. "Emergent" is the structure that emerges as we
learn and accommodate to new and changing requirements (like
resolved uncertainties from an earlier cycle, differently
understood requirements in the light of more context, etc.).
Of course, you get emergent architecture when there is no
explicit or intentional architecting—for example, in the
flavor of agile that downplays architecture. (This is also
called accidental architecture.)
The key, really, is "and"
thinking—intentional and emergent. Collapse the
learning timeframes, make the cycles much shorter, and
Pareto the learning—fail faster and cheaper, improve the
system concept and system structure in quick and dirty
cycles, pull back, mature the system concept and the
architecture. Experiment! But don't necessarily (or first)
experiment with real users at scale! Do the early
experiments much more cheaply, much more quickly! Refine the
target, then fan out and build using an agile process but
maintain an explicit focus on architecture that allows for
emergent design adaptations to be intentionally assessed and
explicitly incorporated into the architecture, or explicitly
reworked to maintain alignment with the architecture. If the
system is complex enough that it can't be built by a small
team, then there must be an explicit architect role, for if
the architecture is no-one's responsibility, it will
give way to what is everyone's
responsibility—feature delivery to the drumbeat of the
incremental release clock.
Grady Booch has said "The code is the truth, but it is
not the whole truth." To that I would add, the code
(alone) is also a very hard truth to get one's head wrapped
around—neigh impossible when the number of lines of code
runs upwards of hundreds of thousands, even millions. When a
system is that complex, we glob on new stuff
Frankenstein style, fearful of messing with what went
before.
That's emergent architecture with a very accidental flavor.
Or we can work with engineering discipline to maintain a
better understood, more carefully managed architecture that
is both intentional and emergent—an intentional
architecture that is built through an incremental and
iterative process that pays its dues to architecture.
Piecemeal growth leads to those romantic-looking old New
England farm houses—which we have so embraced into our
aesthetic that new homes are built in Bloomington Indiana
with that added-onto New England farmhouse look! But have
you tried to heat an old New England house? Emergent
architecture still is subject to structural forces and
quality demands, and these are hard to achieve
unintentionally!
11/18/08 The
Storm is Upon Us
Cutter is calling for papers for the Cutter IT Journal (Abstract
Submission Date: 21 November 2008; Articles Due: 9 January
2009):
"Managing Enterprise
Risk in a Failing Economy: Is it time for Risk Management 3.0?
Many economists believe that the risks present in the current
economic downturn have the potential to repeat the Depression
years of the 1930s. Already, two trillion dollars have been lost
in American pension accounts; another trillion (or two) more is
needed to bail out banks and now insurance companies; one in six
homeowners owe more on their mortgages than their homes are
worth; 240,000 workers lost their jobs in October; and the big
three automakers are at serious risk of declaring bankruptcy
with the potential for a million jobs or more lost.
The economic crisis is not confined to the US but goes across
the globe. The UK is in a recession for the first time in 17
years. The Bank of England has slashed interest rates to the
lowest level in nearly 50 years in an attempt to stimulate the
country's economy.
Governments across the globe are struggling in their attempts to
stabilize their individual economies from the financial
contagion that started with subprime mortgages and has spread to
the near prime and prime mortgage markets, and then on to the
financial credit, corporate credit, and consumer credit markets,
including auto loans, credit cards, student loans, and so on.
Trillions of dollars are being committed by governments in
coordinated risk mitigation efforts to try to prevent a total
global economic meltdown."
Guest Editor: Robert
Charette, Email from Cutter, 11/18/08
Harvard Business Review will have a special section titled
"Navigating the Downturn" in their upcoming December issue.
And they sent all current subscribers a link to a free
article titled "Moving Upward in a Downturn" with this in
the cover email:
"Cut costs radically,
reduce headcount, and hunker down until signs of a recovery
are in sight—that’s the conventional script executives
follow in a downturn.
But what if your company could actually improve its
competitive position during a slump?
In “Moving Upward in a Downturn,” Darrell Rigby says that
smart companies can exploit industry downturns to harness
their unique opportunities. Rigby studied hundreds of
companies and found that the recession winner placed
counterintuitive bets to outperform slumping competitors.
HBR published the article in 2001, after the dot-com bubble
burst, but its insights remain salient and important today.
... I urge you to read it and think about how Rigby’s ideas
may apply to your company.”
email to HBR
subscribers, 11/17/08
I
guess that's it. Feel free to panic now. Forget "hope"
and "Yes, we
can!" Or... not...
If we let it, the underbelly
of reality will smother us these next months and perhaps
even years... Staring into the dark navel of
our perceived misfortune self-justifies our misery—at
least, I tell Sara that (though less morbidly) when she
goes into a fit whenever she tells herself a story about
her own mistreatment by me/others/life... I'm not
saying you do that. I'm only saying don't do
that. It's a trap! I know—I was fully caught in that
negative navel-gazing last weekend after I got a
bruising eval from an architect in a recent workshop.
Well, my ego was certainly
downsized with that one! (The question is, was it
right-sized? Being now about the size of an atom, and still
vulnerable to further imploding. Ok, I'm joking... but
... that's not an invitation to further test my
resilience!)
How
we frame up the narrative we tell ourselves
about an event or
circumstance, impacts (even shapes) the outcome we get.
Our reality is constructed—we interact with external
events, and make meaning of them by constructing
narratives for ourselves. This is essential to memory
and learning, but also to whether we are optimistic or
pessimistic, energetic and creative in facing our
challenges, or not.
Shift happens. How we deal with the shift is up to
us.
At a recent workshop, an
architect noticed a fly in his salad and told the
wait-person, who apologized and said "have
some ice-cream, there are no animals in that."
Life is funnier than anything I can make up! Isn't that
just the greatest lesson in reframing? I had just eaten
the salad, and even from the vantage point of wondering
what unexpected livestock I had just consumed, I was
rocked by the humor and optimism in that. No-one else
seemed to see the humor and I couldn't contain it, so I
called Dana and told him, and he about bust a rib!
If
the star of our story went around making the worst of
everything, she would have scuttled fearfully away. But
to her, ice-cream is a salve! Ok, now I recognize that
someone else may have thought that was a horrid thing to
say to someone recovering from the revulsion of a fly in
their salad (and within earshot of others just finishing
their salad). But I can find the whole situation funny,
in part because I see it as a guileless and sincere
piece of advice from someone who has a daily struggle to
buy milk and bread. And in part because her frame of
reference is so far from that of the person she's giving
advice to, that her advice seems crass and
uncompassionate, and totally inappropriate to the person
she was trying to appease. These "Muriel's Wedding"
moments are life's priceless joke on us. ["Muriel's
Wedding" is a grit-your-teeth-ugly,
steal-your-heart-redeeming,
in-your-face-plebian-not-to-mention-kitsch and
overcoming-stacked-odds-faith-in-humanity-restoring
mixture that leaves you wondering if you loved it or
hated it. That, and the Abba music that has pretty much
the same effect! Ultimately, I concluded I loved it, and
memorably so, because it has been years since I watched
it. But, perhaps it belongs with The Holy Grail—better
in my distant memory?]
Of
course,
Rashomon deals with these individually constructed
realities, ... and the dark underbelly...
Anyway, the lesson is — I need to construct a reality,
interpret even the events that threaten to derail me,
with humor and optimism. It is hard, when our feet are
cut out from under us in this economy... or when someone
forgets they're giving feedback to a person, not a
organizational machine. This is not the same as
being out-of-touch with reality. How we encounter things makes
such a big difference to our internal spirit and to the
knock-on effect we have, and that comes back to impact
our outcomes.
So, humor and optimism.
On
the BodenUSA (a
retail site with Brit wit and designs available in
the USA) home page, the first line is:
"As the old
proverb goes, one kind word can warm three winter
months."
Optimism and humor. So, go buy those 2 good boots and a
chunky knit. Keep the wheels of commerce spinning this
season. And spread the kind words. As money gets
tighter, we still have a wealth of kindness to share.
11/17/08 Another Book Recommendation, and
The Wheel
Daniel Stroe recommended Andy Hunt's
Pragmatic Thinking and
Learning: Refactor Your Wetware, adding:
'I like one of his
quotes, a Plutarch dictum, " The mind is not a vessel to
be filled, but a fire to be kindled."'
This put
The Wheel in a new light for Daniel—the key lesson it
conveys is that "the collective mind has to be kindled."
Daniel has been the first to confess, and brave he is,
that he at first thought I placed too much emphasize on
The Wheel in
Getting Past "But". It is one thing to shrug my
choice off as foolishness, and another to be open to the
notion that there must be some bigger sense to be made
of it. I'm so glad Daniel did leave this possibility
open because his conclusion, that kindling of the
collective mind, is the essential message of the story.
I'm so happy to have those words to express it, thanks
to Daniel and his intellectual engagement with
Refactor Your "Wetware" and The Wheel! That
is classical integrationist thinking. So, add
The Opposable Mind to the list— remembering that it was
Daniel who recommended The Opposable Mind to me
in the first place!
Of course, "kindling the collective mind" is a superb
condensation of passages like:
Antoine de Saint
Exupery [wrote] “If you want to build a ship, don’t drum
up the men to gather wood, divide the work, and give
orders. Instead, teach them to yearn for the vast and
endless sea.” This quote resonates, but not because we
think that sailors necessarily make better shipbuilders.
It is, instead, that the idea of creating a shared
yearning, a common quest, is so important to communal
creative endeavor. Then, building the vessel that will
take us where we want to go will be an inspired venture
that generates goodwill enough to surmount the
challenges. on page 15 of Getting Past "but"
I'm so glad to have the term. And Daniel's frankness. Now,
I did recognize that using
The Wheel was a risk, but I took it anyway because it
contains the lessons we, as an industry, have been
wrestling with, lessons which are out there, but which
are spread out in this book and that and that ... and
that.
The Wheel is also a great test of attitude—if we
allow ourselves to think it is irrelevant (just a
children's story), we've told ourselves a story of our
own creating that prevents us from seeing all that it
holds. I'm so glad Daniel held on to the hope that my
(extensive) use of The Wheel would reveal some
quintessential nugget of wisdom if he let the
possibility remain open. Ah, "first
to dream, and then to do." In addition to
exhorting us to kindle the collective mind to get big
things done, The Wheel, of course, is very much
about how to kindle the collective mind, and what
to do.
Daniel (whom I've characterized as my scout), pointed me
to the movie
The Emperor's Club some 18 months ago.
Now, I have to confess I have also come to see the
central thesis (defined in the opening scene and
elaborated in the movie)
"Finis origine pendet: The end depends on the
beginning" in a new
light. It is not just what we bring—our experiences and
history, our genes, our personality.
It is also our
expectations and attitudes. Attitudes shape outcomes.
Dana says "goodwill is the silver bullet." A positive
attitude, positive expectations, openness—a willingness to
suspend disbelief, a willingness to have the fire be
kindled, these are critical forces in the crucible of
individual and group creativity and learning.
For me, two phrases that stand out as
gems in the crucible of software experience are (Booch's)
"awe-struck
seeking" and (Daniel+Andy
Hunt's) "kindling
a fire in the collective mind."
These allow us to reach, to accomplish great
things—with and through other people.
The same drivers that make
architecture essential, make it mission critical that we
take that "with and through other people" seriously. We
just can't build complex systems alone, nor, generally,
even in a small, closely-knit team of super-developers.
Even if we could, on our own, design a great
architecture, we'd need to get it out of our head and
into the heads and hearts of other people to build and
evolve it.
And more likely, to design a great architecture, we need
to collaborate.
11/20/08 Today's Reading
I've been reading
Proust and the Squid.
Why do I think
it is relevant? This sums up
the attraction:
'Wolf focuses on
the physiological character of the human brain, which
holds at its disposal "three ingenious design
principles: the capacity to make new connections among
older structures; the capacity to form areas of
exquisitely precise specialization for recognizing
patterns in information, and the ability to learn to
recruit and connect information from these areas
automatically."'
Washington Post Review
Ok, I'm also reading
Systems Engineering with SysML/UML: Modeling, Analysis,
Design.
11//20/08 Birth of the Chaordic Age
Jonathan (at least, I think it was Jonathan),
recommended
Birth of the Chaordic Age at a recent
workshop. This from the summary on Amazon:
"Hock introduces
the concept of chaordic, an adjective referring to the
behavior of any self-governing organism, organization or
system which blends elements of order and chaos.
Chaordic organization is one able to maintain a
harmonious order-disorder balance, characterized by
principles of evolution; its nature includes being
self-organizing, self-governing, adaptive, and
nonlinear."
Jonathan was thinking it would be more interesting to
folk in the financial industry. Still, the notion of
chaordic as described above seems broadly applicable.
Certainly the synopsis sounds just right for an intentional
and emergent approach to architecture.
Also at that workshop (Role of the Architect), Darren
recommended Rob Cross'
tool for mapping networks of influence.
11/20/08 Deeper Undercover
My undercover journal has increased in hits to the point
where it tracks at about half as many hits as my more
sterile and superficial, but less wordy, "public"
version. The return rate on guests to this site is also
up. That's all very nice, but it makes me
self-conscious! So, I've decided to create an
undercover-undercover journal. Grin. It's just hard to
draw the line, to find the right balance of interesting
(to me) and professional (to you). So, this version will
still be wordy, but I'll try to exclude the entries with
too much me in them! This entry, for example, would have
to be axed, except that if I tell you I'll try to put
put less me on this page, then hopefully you'll hold me
to the promise if I falter!
11/21/08
Organizational Considerations and Reuse
- Danielle Fafchamps, Organizational Factors and
Reuse, IEEE Software archive Volume 11 ,
Issue 5 (September 1994) Pages: 31 - 41 Year of
Publication: 1994 ISSN:0740-7459
Danielle has a PhD in anthropology, and she was a member
of our Flexible Software Factory project team under
Martin Griss in the Software Technology Labs at HP Labs
in the '93/94 timeframe.
Of course, there's also Martin Griss' compilation of all he learned about reuse in
Software Reuse: Achitecture, Process and Organization
for Business Success, by Ivar Jacobson, M. Griss,
P. Jonsson, 1997.
For a different take, see
The Selfish Class, by Foote and Yoder
11/21/08
Dreams, Goals and Journals
Sara is in a Writer's Circle for girls ages 8-14. We just
got email to say they are having a special event early
in the New Year. The agenda:
What are your
dreams? How have great leaders of the past and present
made their dreams a reality? This workshop will focus
on using writing to describe your dreams and your
talents, and to reflect on ways that you can use your
talents to make your dreams a reality. You’ll make a
personalized journal to keep track of your dreams and
your progress towards your goals.
Sisters of the
Flying Fountain Pen writer's group email, 11/21/08
11/21/08 Great Grove Graphics Example
UCSF Strategic Vision for Educational Technology
2003-2008
11/22/08 Clouds From Both Sides
I was scanning in some archman drawings that were
backlogged, waiting for an idle Saturday night I guess.
And I came across a sketch of clouds and boxes, meaning we
start out with uncertain, fuzzy ideas and work towards boxes, that
become constraints—building blocks that enable, and
boxes that box us in. Then I remembered
Rumbaugh
serenading Booch. And it occurred to me that we ought to
take another look at clouds.
So, I looked at the
original lyrics and they are perfect!
"So many things I would have done
But clouds got in my way
I've looked at clouds from both sides now
From up and down, and still somehow
It's cloud illusions I recall
I really don't know clouds at all"
Both Sides, Now lyrics by Joni Mitchell
All the things we'd do differently, if we realized that
when we start out we're dealing with clouds not boxes!
Indeed, we need to be working with clouds, not
boxes. Given our bias to action, we tend to rush
forward treating the first concepts as boxes to build
on, and they become boxes we build within. We do need to
spend some time, not too much mind, seeing the possibility of
the clouds—feather canyons everywhere. Not just rain
and snow and obstacles of our own inventing, of
not doing.
If you're trying to make sense of the annotations—I was
thinking about our early draft architectural elements
during the first passes at Conceptual Architecture, and
reminding myself that they are just our first stab at
architecture elements. As we iteratively explore
different views and experiment with alternatives, we
refine and refactor the responsibilities of the
architectural elements. It would be good if we
recognized that early on, we are working with constructs
that we need to treat as highly mutable; when they
stabilize and we gain confidence in our boxes we can
put them under some degree of change control, but until
then we need to work to keep them from becoming
hard-cast in our own minds too soon. Now, I'm
not saying we have to draw them as clouds, but it is
good to remind ourselves to treat our "boxes" in early
iterations with a very healthy degree of skepticism and
a heavy hand on the eraser.
12/23/08 Your Help Getting Past
My "But..."
Over the Christmas slow-down, I plan to draft the
Getting Past But book. It might well need a new
title, but right now I like the exhortation to me
to get past all the "but" arguments I put in the way of
getting it done. So, if you have enthusiastic
collaborative input; good, positive things to say; and
helpful ideas for extending the
Getting Past But paper, I'd very much welcome them.
If you have criticism, please
reserve your comment until I'm over the creative
hump of getting the thing drafted. As always, there's no
need to take a baseball bat to my ego—I have my own
internal Dobby to beat myself up.
Why "Getting Past But"? Well, I think it has a
broader audience, and it is that audience that
architects keep asking for help with. So I figured that
is more urgent than anything else. Help change the
environment so that architects can get good, right
systems built and be successful in delivering value to
their business. If you want to change the outcome, don't
try to change the people, change the context! You know, using elephants to
smuggle donkeys.
11/25/08 Right or Appropriate
In the past two days I've seen two architects in very
different contexts say they are not about creating a
"right" architecture, but an "appropriate" one, or one
that fits the organization's capabilities—by
implication it is a compromise on "right." So, I just
want to re-iterate that when we say "right" (as in
"good, right, and successful"), we define "right" in
that context to mean it meets stakeholder needs and fits
the context. In other words, the system has good
fit-to-purpose and fit-to-context (potentially across
market segments or customer groups). This necessarily
entails compromises, or judgment calls on what is good
enough, on the part of the system definition team
(including, if not led by, the architect) as they set
priorities and make tradeoffs.
So, we're all in agreement that architecture is about
compromise, tradeoffs, good-enough. If the word "right"
implies "perfection" in your community, then steer clear
of it! Don't let a word stand in the way of doing what
is right—ok, ok, important! Grin.
And we need to bear in mind that good-enough is only
good-enough where we need to be at parity with
competition; there are some dimensions along which we
need to excel, if this is a system that impacts our
business' competitiveness in the marketplace. We need to
understand where lies the heart of differentiation for our
system or business, and defend that.
Unless you're Steve Jobs. Then brook no compromise. Just
kidding. Even Steve jobs gives up on something—in his
case, he has given over the lower end of the market to
others, because perfection costs.
Roger Martin
calls for a "no tradeoffs" mindset, but
fundamentally there are going to be choices to be made.
One choice may be to set
BHAGs and push the
circle of excellence to its outer limits. But there
will be outer limits, and so there will be tradeoffs.
But we can strive to achieve more than we at first
expect. Set goals that stretch beyond what our first
instincts told us. Find the integrative solution that
gives us more of both, rather than less of one to get
more of the other (the stuff of tradeoffs).
11/25/08 When Talking is Doing
I have my own set of "word allergens," and IBM's "Talking
uses energy, doing creates it. Stop talking. Start
doing." commercials number among them. Grin. Of
course I know full well that the defending reaction would be that
by implication we've already been doing a lot of talking
and we're just procrastinating on the acting.
Nonetheless, messages like these borrow energy from, and
give energy to, those of the "ready, fire, aim"
mindset—those who would think we should hold no truck
with talk, and get on with doing.
The trouble is, unless
we talk, unless we enter into careful and rich dialog,
we are not going to understand the needs and
constraints, the frustrations and the goals, the good
ideas others have, and the good ideas we get when we
interact with others, that open
up avenues to opportunity. As architects, we work
across—across the system, across products, across
business units. Unless we actually enter into dialogs,
unless we draw out the common needs and the
differentiating differences across these stakeholders
(in the business as well customers), we can't do our job
of architecting—well, we're not going to get to
"right"—to a solution that balances needs and exploits
opportunities to create strategic value for the business
by taking a system approach.
Then there is the whole
"model out loud"/"model in pairs/small teams" and "get
stakeholder input early and often, as the architecture
is iteratively designed" set of values that draw the
agile principles into architecting—these make talking an
integral part of doing. And, for larger systems, there's
getting the architecture out of the head of the architect(s) and into the heads and hearts of the full
development team, and that takes talking and drawing,
and writing, and more talking, explaining, defending,
amending, and justifying and more drawing, to do! Did I
mention talking and drawing? Ah, but still not enough!
Never underestimate how much talking and drawing is part
of doing for the architect! We need to draw out good
ideas and opportunities in system concept generation.
We need to draw on the expertise and the perspectives
of others in system design. And drawing, modeling,
graphically facilitating, helps the conversations be
focused and highly motivating—when input shows up on
the shared picture there's that "I see what you
mean" integrative response and "our picture" kind of
ownership. Strategic conversations, exploratory
conversations, rapport building conversations, these are
all important when we recognize that building complex
systems is a socio-technical process.
11/26/08 Congrats Bredemeyer!
This just in:
[Subject]
"Congratulations on Bredemeyer Consulting's 10-Year
Anniversary!
Hi Ruth and
Dana,
I just
visited your website and saw this announced.
What a milestone! Well done!
--Elizabeth" personal email, 11/25/08
That made our day! Our clients are the world's best in
every way. Top companies, top people and you are
really, really all-around good to work with! I was
reading "What's
Missing from the Agile Manifesto" and that joy point
struck me. The people around us deserve joy, and how is
it created? The opportunity to do good work and be
recognized for it goes a long way. There is a ton of
recognition in Elizabeth's simple words. Recognition of
a lot of hard work and sacrifice to the "cause" of
helping to birth a field—one that combines
discipline and art, craft and engineering, invention and
application of lessons from experience, all these things
and more. During our first year, together we earned less
than one full-time equivalent in salary, and then
gradually built up to the point where we could pay
ourselves what we were earning at HP when we left. What
we have given up in salary and benefits and career
growth at HP, we gained in being able to set the
agenda—pursue what we believed was important for
architects, figuring that out, building a portfolio
around it, growing ourselves and our insight. There's
sacrifice but there's also joy in that. And joy
especially when someone else who's been on both sides of
the Fortune 50 and small company side of the fence,
takes the time out to implicitly acknowledge all that it
took to get us to this point.
11/27/08 Thankful for...
Daniel sent a thoughtful Thanksgiving note,
congratulating us on Bredemeyer's 10th, and saying "I
am glad that I had the great chance meeting you."
That's so heart-warming—to be someone it was good to get
to meet. I assume that is a recognition that I go
through life with my internal lights brightly lit, and I
so know what it feels like to appreciate that in others!
I get to work with such great people. Dana too—he'll
come back from a workshop and go "ah, this guy and this,
there's such a sense of simpatico" and he means with
respect to architecture but also with respect to life.
Embracing life with gusto, seeking, exploring, standing
still only to see, and feel and understand, not to let
the dust settle. Remarkable people. People who have
enriched my life, challenged and taught me (mostly
gently, always generously), inspired me, made me laugh
(special thanks Kurt for his Thanksgiving note), and ...
much more that I'd write if I didn't have to go back to
the (extended) family and be sociable.
11/27/08 Microsoft's Handbook of Software
Architecture
This, by way of email from Rob Boucher at
Microsoft:
"Main link.
http://www.codeplex.com/AppArchGuide
Microsoft
patterns & practices is rewriting the Application
Architecture Guide published back in 2002. (See
OLDER guide at http://msdn.microsoft.com/en-us/library/ms954595.aspx)
. This is probably one of those few projects that
any developer (at least in the Microsoft space)
should know about. It’s guidance for building
solutions on the MS platform, but we kept much of it
applicable to non-Microsoft cases as well.
We are
currently in the BETA2 for the project, with a
release after Dec 15th 2008 and before Jan 15th
2009.
This project is
made up of a book, a knowledge base and a public
contribution site. The Knowledge Base greatly
expands on the information provided in the book.
There are How Tos, Cheat Sheets to help you pick
technologies, videos, sample applications with
code(planned) and more that will be expanded over
the next month or so. The contribution site is for
the public to add their code and guidance as well.
Guide site
http://www.codeplex.com/AppArchGuide - in BETA2
Knowledge Base
http://www.codeplex.com/AppArch
Contribution
site
http://www.codeplex.com/AppArchcontrib (just
setup)"
11/28/08 Reuse and Complexity
Charlie Alfred has posted
article 4 in his complexity series, dealing with
product platform/reuse decision making from a complexity
frame of reference. Great post!
11/28/08 Architect Soft Skills
It's been a few weeks since I checked in on Arnon
Rotem-Gal-Oz, and see he has a nice post on
architect soft skills. The point about the king
under Organizational Politics, for example, is classic
Arnon wit and wisdom:
"You just look at the
alternatives; analyze the merits vs. the problem at
hand, and may the best option win. This works out well
if you are the king (or work alone which makes you the
king by default) -- otherwise there are other people and
they won't necessarily agree with you."
Arnon
Rotem-Gal-Oz,
Architect Soft Skills,
10/26/08
11/29/08 Power of Pictures
Some useful links on visualization:
The power of visual analogy:
'In education, a
Grace Hopper nanosecond is a prop used by a teacher to
help students understand an abstract concept. The
teaching tool got its name from the foot-long lengths of
telephone wire that Admiral Grace Hopper used to give
out at lectures. Admiral Hopper used the wires to
illustrate how in one billionth of second (a nanosecond)
an electronic signal can travel almost twelve inches.
...Admiral Hopper
believed that by providing the learner with a concrete
analogy already in their frame of reference, it was
possible to absorb and even understand an abstract
concept that might otherwise be too difficult to
comprehend.'
Grace Hopper naosecond, Whatis.com
Architecture as a Language, by Markus Völter.
11/29/08
Miscellaneous Architects Architecting Architecture Links
11/29/08 Custom is as Custom Does
A man, recently
married, watches his wife prepare a roast for dinner. To
his amazement, just before placing the roast into the
pan, she slices off about two inches of meat on either
end and throws them away. When he expresses surprise at
her actions, she replies, "It makes the roast taste
better. Besides, my mother always did it that way."
Curious, he calls his wife's mother and asks her if she
also cuts the ends off of her roasts, and why. "Because
it makes the roast taste better. Besides, my mother
always did it that way." Determined to find out where
this custom comes from, he calls his wife's grandmother,
and when she agrees that she, too, cuts off the ends of
her roasts when she prepares them, he asks why.
Promptly, she replies, "Because my pan is too small to
hold it all."
Ted Neward,
Pragmatic Architecture: Layering, October 2006
11/29/08 Getting Past "But..."
On collaboration among experts with different
perspectives, Armano says:
"Resist the urge to
become defensive and territorial—put that energy into
developing an acute sense of curiosity and optimism.
Become like a child."
Creativity 2.E:
The
Evolution of
Creativity is Underway,
David Armano, 6/24/06
Armano makes the same point as our
Getting Past "But"
executive report, but in 2 sentences. Back to the
drawing board! Even there, I was prefaced by Frank Lloyd
Wright:
"An
architect's most useful tools are an eraser at the
drafting board — and a wrecking bar at the site. "
– Frank Lloyd Wright
11/29/08 Misc. Innovation Links
-
Innovation Through Design Thinking, Tim Brown,
MIT video
-
Endless Innovation
-
The Recession--Is There an Upside to the Downside?
Bruce Nussbaum on November 19
-
InnovationTools
-
Democratizing Innovation, Eric von Hippel (GoogleBooks
preview)
-
Story of 3M in
Scott Berkun's Innovation talk (around minute
21) [see also philosophy document by William
McKnight, Chairman 3M, 1948]. Berkun also points to
all the failures that took place in getting to the
moon, and recommends From the Earth to the Moon,
Tom Hanks mini-series, episode 5.
-
"The walls between art and engineering exist only in
our minds." Theo Jansen,
BMW, Defining Innovation
11/30/08 Why Innovation Matters
Innovation in a downturn
11/30/08 Note to Architects: Career growth is about
moving from "how to" to "where to"
'One entrepreneur said to me over
the weekend, "You know what my
problem is? I'm the how-to guy. I've
got all the knowledge needed to run
the business and give the clients
what they want.
But that's not going to get the
business anywhere spectacular, fast.
I've got to become the where-to
guy." That means clearing the desk
and becoming the strategist, the
leader, the innovator.'
Why Innovation Matters,
blogs.theage.com.au, 9/5/07
Ok, the Visual Architecting Process is about
both: "where to," and then "how to," and "how to" is a
lot about tuning up "where to."