You wouldn't plant seeds in a desert unless you had
a way to get water to them. Some organizations are just inhospitable to
architectural seeds: wandering in the desert*,
rampaging elephants and all that. So, while I generally urge taking
ownership of the excuses we erect with "yes, but," I do recognize that
there is a lot of spread in receptiveness to (intentional) architecture,
and some organizations are intensely hostile to it—intense to the point
where the architect has to decide whether he/she has the passion to
persevere, or find a new environment. We wouldn't have the US
Constitution if it weren't for the perseverance of James Madison.
Amazing Grace is a great story of hard-won victory against strong
and persistent opposition. Across history, important changes have been
wrought by determined individuals and groups. They have worked doggedly,
and with political savvy to navigate around obstacles. Even so,
sometimes taking one's passion and talent to a new venue where it can
flourish is a good move, big picture. Along those lines, I have a couple
of backlogged architect job posts I need to add to the
jobs listing page on the Resources for Architects website [ok,
And, I have to say, for all her sweetness, Sara is
here to remind me that it can be downright unpleasant to be on the
receiving end of dogged persistence! Endless nagging, never letting no
be no, can raise it's own set of barriers. Oh yes, Ryan and Sara are
quite taken up with the Getting Past But idea. When
about to answer "but" to some get-ready-for-school urging this morning,
he substituted "elephant" for "but" in his sentence. Getting Past But
is raising awareness of how readily we hide behind ... "elephants."
In one scenario, accidental architecture is simply
a trial-and-error response to novelty. In another, accidental
architecture is the result of accommodation after accommodation in
response to environmental stimulus—change in technologies, change in
needs or interpretation of needs, a broadening market base, and so
forth. Thus, accidental architecture might be quite well adapted to the
current environment. But it may not be. And in another scenario,
developers are allowed to make any decision
they wish either because there is no architecture or the architecture is
not taken seriously. Then the architecture is accidental, rather than
intentional, and the real strategy of the business is emergent
from their decisions, to the extent that what the business is able to
do, is dependent on its products, services, or operational and
Strategy determines differentiation; that is,
strategy seeks to be a shaping force in the competitive landscape.
Intentional architecture takes the current environment into account, and
explores how to deliver differentiation not through ad hoc
adjustments to the competitive environment, but by delivering the
capabilities demanded by the strategy.
Of course, even intentional architectures tend to
be compromised under schedule pressure and pressure to tune to
specific/local environmental (use context) concerns. Accommodations
seem adaptive, and they generally are—short-term. But near-sighted
accommodations can quickly erode into kludginess that stifles future
agility; we know it as the big
ball of mud. Keeping the architecture clean, simple, uncluttered, is
a big job. And an important one. The architect should be around through
implementation and evolution, to stand under the
capstone as it is lowered into place, to be held to that accounting,
and to hold others to their commitments, too.
"It is an
architects’ job to be a systems thinker, a bridge builder, a
diplomat, and a change agent. One interesting thing is that many
hiring managers don’t quite understand this. They see an architect
as a senior technical leader of a small development team. As a
result, the architect can easily find him/herself in a position of
little leverage. Archimedes said, “Give me a lever long enough and
a fulcrum on which to place it, and I shall move the world.”
There’s a third, unstated phrase in this quote – the position of the
fulcrum. If it is too far from the object and too close to your
hands, you can’t use the lever to move anything."
Alfred, personal email, 2/13/08
image is such a helpful one! We have to help our managers understand
where that fulcrum needs to be placed!
2/13/08 Books and
Daniel Stroe recommended that I read
Invisible Engines: How Software Platforms Drive Innovation and Transform
Industries. And I will, I will. In the meantime, I've returned to "Education
of a Reluctant Businessman" and I'm really enjoying Chouinard's
stories, design perspective, and call to ecological consciousness.
I lift my head from the sand, and discover the
world became a more frightening place while I was burying myself in
the distractions of work.
Madi Hirschland, of microfinance fame, is working to raise
awareness locally. Indiana, you see, is fighting for top spot in the
nation's worst offenders list when it comes to global warming. On
Forbes list of greenest states, Indiana was 49th, followed only
by West Virginia! And Indiana is ranked
in per capita carbon dioxide emissions. It's not that we
consumers are so much worse than others in the nation, it's more
that our electricity is
produced by the
biggest pollution offenders—coal plants. And, apparently, we
export electricity—to our greener neighbors to the west??? And we
state incentives/subsidy for installing solar panels! Still, the
US is second only to China in
CO2 emissions. And one could argue that China's pollution is
fueled by our consumerism; we didn't just outsource our
manufacturing to China, we outsourced our pollution—but the impact
is global. The
New York Times says: "Every
week to 10 days, another coal-fired power plant opens somewhere in
China that is big enough to serve all the households in Dallas or
global warming thing is a mess. Our neighbor has been researching
global warming for years, from an academically serious environmental
physics angle. His concern has been growing, and seeking to do the
right thing, he bought a hybrid electric car. I don't know where a hybrid
falls on the pollution scales, but in Indiana where coal-fired power
plants are spewing carbon dioxide it makes for a conundrum. While it
is hard to tease out the bottom line impact of our "carbon
is clear that we need a small car for day-to-day errands. And that's
just for starters. er... I think I need to do some more work now.
The "real world" is much too depressing! Ah, elephants.
Mohandas Gandhi said "Be the
change that you want to see in the world." First, we have to
see the world. It looks much like it did yesterday. Unless you're a
Or you just read that 1 in 8 women get breast cancer and it is the leading cause of death among women aged
35-54. And your kid has to go to Alaska to eat the fish he
catches. Life's simple pleasures, and life at all, are at stake.
More or less. And
This will impact us. More
than just the ("do no evil") Googles and Amazons will have to look at their
power hungry ways (the concern even made
Dilbert—this link goes bad on 3/11). And we have to look at personal and business
consumption. Right at a time when recession threatens and pulling
the plug on spending could send the world into a tailspin.
Conundrums a plenty!
Chouinard and Patagonia set out to provide an example to the
world, and they're not letting conundrums hold them back. Hard
choices can be made, if you have principles to guide you. But take
heed; the world is changing fast. I was looking at CO2 emission
rankings for 2002 and China was below the bar in terms of offenders,
and with rampant industrialization it is now top, and growing. And
our greedy ways keep us in an embarrassing position.
Obama says: 'And
I will send once more a message to those yearning faces beyond our
shores that says, "You matter to us. Your future is our future. And
our moment is now.” '
Those are not yearning faces any more. Those are
pleading faces, and we need to heed them. And
Hillary has a
plan to do that. Whatever your political leaning, the world will
be better off if you lean on clean.
For counterpoint, see
Michael Crichton's essay on
Complexity Theory and Environmental Management.
Books and paper things
Paper (digging into
architecture archeology) I speed-read yesterday
(don't quiz me on it):
Here's a little piece I did
that alludes to
my approach to architecture archeology.
Books I've returned to
reading this week:
Books I'm looking at buying:
Distributed Event-Based Systems, by
Ludger Fiege, Peter Pietzuch
Event-Based Programming: Taking Events to the Limit, by
Enterprise Architectures, by Michael,
SOA Design Patterns, by Thomas Erl
(due out in May, 2008)
SOA in Practice: The Art of Distributed System Design,
by Nicolai M. Josuttis
Catalyst Code: The Strategies Behind the World's Most Dynamic
Companies, by David S. Evans, Richard
Doing What Matters: How to Get Results That Make a Difference -
The Revolutionary Old-School Approach,
by James M. Kilts, John F. Manfredi, Robert
Leadership and Self-Deception: Getting Out of the Box,
Richard Watson’s new book
Future Files: A History of the Next 50 Years (due out in
I'm interested in system
health and business intelligence, so want to ramp up more on
event-based systems. Do let me know what you've found helpful in the
event-driven architecture space. My interest in SOA and EA needs no
comment. Catalyst Code is the follow-on to Invisible
Engines. Doing What Matters is by Kraft/Nabisco/Gilette
CEO Kilts. Not relevant to IT/architecture as strategic enabler?
What about this:
"During my tenure at Kraft, we
developed something called IMI - Integrated Marketing Intelligence -
which gave us state-of-the-art insights into our brands, their
categories, and consumer dynamics; how responsive they were to
different forms of advertising and promotion; how much spending was
optimal; and much more that will be explored later [in this book].
When we spent marketing dollars at Kraft, we were truly investing
in brand building." (Page 94, Doing What Matters)
How you put together
information to create business intelligence is strategically
interesting. It is taking information systems to the next level; not
just replacing route work by digitizing it, but using information
and events to support competitive intelligence.
Books in my cart:
What am I missing???
Happy Valentines Day!
wonder, the joy, of working with architects, is that I get to
interact with people who shine; smart, creative, investigative,
multi-dimensional people. People who lead me." moi,
Day to you!
Someone pointed out that there was no
scaffolding in my "cartoon"
of the Roman "architect" standing under the arch as the capstone is
lowered in. I had to smile! Any guesses?
2/16/08 "3 Circles"
We developed a "3 C's" (capability, commitment
and culture) model for architecture readiness assessment. Now we
have another "3 circles" model (knowledge of customers, knowledge of
capabilities, and knowledge of the industry) for innovation. It
could have been 3 C's, but using competition instead of industry is
strained and misplaces attention. The idea is to beat competitors,
but not in an incremental nose-to-nose feature race for a market
position, but rather by understanding value networks and flows, and
opportunities to truly differentiate by delivering unique and
compelling value to customers and users.
Technology-driven innovation is technical
capability in search of a use. Like
Segways finding a niche in airport and mall security.
Market-driven approaches seek to understand the day-in-the-life of
the customer, and find ways to add something the customer will
Each approach has worked. But if we want to
make innovation more the way we do business, we need to look at
putting insight into what is possible together with insight into
what is desired, passion for what technology brings to the table
together with passion for making a difference that customers care about.
We need to add another circle if we want to go
beyond simply finding opportunities, to sifting for those that are
differentiating—they make our products or services, and our
business, stand out in the minds and experience of our customers.
who holds insight into customer/user needs? Who holds insight into
our current capabilities and what new technologies make possible?
And who has insight into our business positioning and direction
relative to competitors and the value network? Yes, the center of
expertise for each is different: marketing and business units,
architects, and strategy planners and strategic management.
Innovation happens when you put these together. Yet in most of our
organizations, job specialization and role turf is pushing these
organically in the small, as in startups and incubators, becomes
harder and harder to achieve in the large, where functions are
separated and gatekeepers are placed, and place themselves, at the
organizational divides that form between IT and "the business," or
"marketing" and "development." The
importance of cross-functional teams comes up over and over again.
Difference in perspective, diversity, can have it's rough edges, but
it fuels creativity.
Aside: I went looking for a
Tom Peters quote on creativity (sometimes... I like ... some
of... what he says... like... when he is... quoting others...) and I
found this "The
Birth of the IPM"—I looked for the date to see if it was an
April Fool's Day post... Grin. Well, it sure puts me in
context! I'm a staid product of the engineering world, after all.
Creativity is all very well, as long as it serves getting real work
Don't Go Big Bang!
When we talk about
creating a compelling vision, we are also careful to talk about
creating a path to the vision that does not overstretch the
elasticity of the organization. To illustrate incremental change and
delivering value before resistance sets anchor, we have long been
telling the story of
Jaime Lerner's creation of the
down-town pedestrian mall in Curitiba**, Brazil. You can read
our version of the story in the
Strategic Differentiator paper (pages 20-21) that I mentioned
earlier this month.
Find the value. And find a way to quickly
demonstrate that you can make real on it. This is just as important
to making a personal shift, like "getting past but," as it is to
project visions. This is about incremental change, but it is also
about being careful to take steps that deliver early value.
** If you don't have and don't want a NY Times
account, google "jaime lerner new york times" and you can get to the
article without signing in... Or not; the
command and control thing I reserve for Ryan's dog. I did see a
woman wearing a t-shirt with the following on the back "Sit!
Stay!" and I wanted to ask her
where she got it! There are so many ways I could use that one...
2/21/08 Grady Booch's Memoir (and
"memoir" on the 5th anniversary of becoming very rich, or
something like that. :) It is an interesting read. Of course,
he didn't mention that
Fusion was the first integration of OOAD
methods, including Booch and Rumbaugh's OMT but also Schlaer-Mellor,
Cunningham and Wirfs-Brock and others that Booch neglects to tip his
hat to. But, of course, he was writing a personal perspective on Rational's history,
not the history of OOAD. It is an interesting history; one I'm so
glad to read; thank you Mr. Booch. That said, I just wouldn't want the
industry to forget that other factors influenced Rational's move to
integrate and then lead the push to standardize. It was a good move,
and it got us to refocus from creating Team Fusion which was to be
the next generation of Fusion that would do two main things—address architecture and evolutionary development (a precursor of agile,
and as I understand it, an influencer of Scrum). We
decided to throw our hat in with the UML standardization effort, and
Martin Griss and Reed Letsinger were HP's key men on that one.
Martin started to collaborate with Ivar Jacobson, and that led to
their book on reuse. I continued to focus on architecture, but
no longer exclusively architecture for object-oriented systems.
Anyway, Booch and Rational's leadership was a clear catalyst to the
UML effort. Still, the community got behind it, and it is good to
remember that community support, including the collaboration of
other leaders in the OOAD space, was also critical to UML being
developed and embraced as a standard.
I do want to say that I have had a very
strong respect for Grady Booch from those days working on Team
Fusion. I gave presentations on Fusion at conferences and at OO
shindigs, and had to explain both what made Booch's contribution
great, and what made Fusion an advance on what had been done by
Booch, Rumbaugh and others. Booch taught me so much, and from Fusion
I learned still more! It was truly a
method, in that it supports end-to-end design decisions, not just
spots along the way. In Fusion, structure supports behavior. That
is, designing behavior is integral to designing structure. We have
learned a lot since Fusion. But Fusion, as far as I'm concerned, was
a big milestone on the OOAD path, and I would not want it to be
glossed over by the tellers of OOAD history! Of course, my opinion
here is not unsullied by vested interest. I owe so much to Derek
Coleman, the "father of Fusion," and respect him greatly. He was a
demanding task master, and brilliant. Being British, compliments
make Derek excruciatingly uncomfortable—even when they're being
paid to someone else!!! :)
Well, I'm happy
Booch used the opportunity to tell the story, for it helps reveal
more of his role and contributions to Rational as well as OOAD. And it gave me an opportunity to say I think
Derek Coleman and Fusion are given short shrift by the tellers of OOAD history.
Moreover, I have been privately lamenting that Grady's
early blog years left a much richer trace of his thinking and
exploration, and I miss that. Grady figures among the most important
leaders in our field for good reason, and for all that, he remains a
nice guy with a sense of humor.
Educate by Providing Value (lighthearted for good health)
I mentioned I've been reading
Let my people go surfing (which I like to refer to by its
subtitle, because for most of us engineers-turned-architects it is
the subtitle to our personal journeys:
The education of a reluctant businessman). Well, many things
have struck me which I still need to note in this journal for
preservation of my thought. But this is the part that pertains to my
present train of thought: Early on, Patagonia established a practice
of educating it's customer community with essays in their catalog.
So, they educated customers on the
damage that pitons were doing to rock faces. Yes, they went
after their own core business, deliberately cannibalized it, and
educated their customers on their disruptive innovation, all via a
15 page essay in their catalog. Now, if you think software engineers
don't read, try mountain climbers! Yes, like any community, there
are some who read and some who read... let's just say... less. But
an essay in a mail-order product catalog. Hmmm. They did this again
with layers. They invented an undershirt that wicks away moisture
(modeling diapers), and had to educate their customers on the value
proposition of layering. They treated their customers like smart
people who can and do read when it is of personal value to them.
Hey, what a concept!! Shall I say that again: let's treat our
customers like smart people who can and do read when it is of
personal value to them! Of course, our customers are software
engineers, so, glory be, they are smart people (and many are
climbers, at that; extreme sports and extreme programming seem to go
hand in glove)! The heart of the matter isn't getting them to read.
The heart of the matter is writing what will get them to
Now, I've been reading a client's
(proprietary) architecture document. It is to their company what
Booch's Handbook will be to the world, and more. Very impressive!!
Still, is it for every business person in that company? Good
gracious no! Is it for every software engineer? No again; at least
not in absolute terms. But parts of it are. Is it for every
architect in that company (actually, it's a division of a company,
but a fairly big division). Absolutely, in absolute terms. Every
architect should know at that level every other architecture in the
division. This is not frequently practiced, because too often
architectures are implicit in the code and the architects can't
afford to go spelunking in more than one codified architecture. But
imagine if all the architectures in your division were documented
and in one spot (where the owner architects have to keep it
up-to-date); wouldn't that be empowering? Enable synergies and
reuse, facilitate alignment and consistency, leverage learning
across projects, and so on.
Different views need to be crafted for
different stakeholder communities, and for strategically influential
stakeholders, views should be tailor-made for them. And there's a
standard for that; that would be
IEEE 1471, the "standard" for architectural description.
essentially says architectures have various stakeholders who have
concerns and architectural views should be created to address
We have to remember that we engage
differently with the written word than with the spoken word, and
this makes the written word very powerful. Once we have chosen to
read words, they run in our heads like our thoughts. We can
challenge them in an internal dialog, pass them through the test of
our own experience and reasoning, without losing our place. And if
they wax too flowery, we can disengage. So, enough of that.
Bottom line—write about your
architecture, but make it interesting and valuable to the intended
readers of the document you are writing. If you explain some crucial
aspect of your architecture to the engineers it will impact, adding
to the mix the considerations you took into account, the driving
forces, your insights and experience that made your choices make
sense, odds are they'll find it interesting and valuable. But, I'm
betting on your experience and your ability to communicate it in
diagrams and written words.
And, because unintended use may be made
of your document, be explicit what the intended use is. Otherwise
unanticipated "quality requirements" will be levied against your
document, and it may come under fire only because it is being used
in a way you didn't scope for.
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
in self-congratulation. Ok, quickie quiz: just what part of this is
satire and irony and what part wit?
Ok, that's how not
to do your document scoping! This we call leading by
Uh, I think I'd better go now.
Bills to pay. Life to lead. That's me I'm talking about, though
clearly you're procrastinating too.
I was joking with the trademark thing
(me, joke? no!), and then I thought I'd better check in case I was
infringing, and phew, faith restored in humanity, leading by
is not trademarked! But (sinister laugh) now I have dibs on
;) Bills! That must be it.
I thought it was Scott Andersen's bad influence. Really Scott, humor
in the middle of the day? At work at that! Tsk! Tsk!
Then again, thanks to Scott, Dana is in
less danger of a
heart attach today. Hopefully, I've done my part for you. But,
only if you're in the small and select set... you know, awesomely
smart, great sense of humor, and ... you have a certain amount of
tolerance for my quirkiness...
2/22/08 A Note on
Ryan is the master of minimalist or
parsimonious writing. Of course, in this journal I'm on the other
extreme and I recognize that parsimony is hard work. Ryan labors at
his strictly elemental reports, with not a single superfluous word.
He can summarize an entire novel in half a page, including every
important element of the plot and character development. I takes him
twice as long to write his book reports as it does for the others in
his class who write 10 pages or more. And then, are they interesting? Well,
only as an intellectual exercise in assessing accuracy and
There is a difference between minimalist
architecture (keeping the decision set minimal, and the blueprint
elemental) and doing what it takes to breathe the architecture to
life in the minds of the development community, and to keep its
sponsors fully on board as reality throws fake feeds at the scrum.
The management team may need sound bites with a liberal sprinkling
of "innovation," "excellence in strategy execution," "business
alignment" and "attract the best talent." (No, I'm not leaking
your competitive strategy, I'm leaking everyone's
competitive strategy!!! Hmmmm! Oh yes, context matters!) But
the point is, if our system is strategic so that successfully
getting hearts and minds engaged is crucial, we need to think about
our audience and deliver our architecture to them through different
routes. Participation is one. And interesting reading that delivers
value to the reader is another. See the Outcomes and Deliverables
section (starts on page 5) of our
Minimalist architecture papers:
2/22/08 Architect Jobs
I just added two more
architect job listings to the Bredemeyer
Resources for Architects
site (so in the last week I've added listings for a software
architect, senior data architect, senior enterprise systems
architect and enterprise architect). I think this is the tip of the
iceberg, as we keep hearing about internal development and hiring
plans that reflect a growing demand for architects, and a growing
recognition that architects play a role that is key to value
delivery and risk management.
In areas where capital equipment is
invested in, there is a notion that these investments have a
lifespan, or alternately put, the equipment becomes out-of-date and
even if well maintained, has to be replaced. Our software systems,
too, have to be modernized. Some approach this modernization by
carving up old systems and giving the chunks a new coat of
integration paint. This is all very well for systems that are not
central to our differentiation strategy. And it may even be just
fine as a migration strategy for core systems, where any change is
risk. But we do have to think very carefully about where our
strategic systems need to be 5 years out, and have an investment
plan and technology roadmap to get us there. Craig Jordan talks
about the need to envisage the mosaic, when you're creating the bits
of tile—the A in SOA, that must come first, if we want
architecture not accident.
Yes, a growing demand for architects, so we can chart new
systems and bring old ones into the future. A wave of expertise
will be leaving our industry as those who pioneered it take their
bows. At the same, we stretch our complexity boundaries in ever more
ways, raising the demand for innovators and complexity handlers.
There will be more opportunities for technical specialists or
"structural engineers," and there will be more need for the
architects who create the "big picture," the design that allows all
the pieces to work seamlessly together to deliver differentiating
value in all its dimensions, from function to quality to life-cycle
Einstein versus Zen Master
"Perfection of means
and confusion of ends seem to characterize our age.”
Yvon Chouinard said:
"I've been a student
of Zen philosophy for most of my life. In the practice of Zen
archery, you forget about trying to achieve the goal—which is
hitting the bull's-eye—and instead focus on all the different
movements of shooting an arrow. You practice your stance, reaching
back and smoothly pulling an arrow out of the quiver, notching it on
the string, controlling your breathing, and letting the arrow
release itself. If you've perfected all the elements, you can't help
but hit the center of the target. The same philosophy is true for
climbing mountains. If you focus on the process of climbing,
you'll end up on the summit. As it turns out, the perfect place I've
found to apply this Zen philosophy is the business world."
p74-75, Yvon Chouinard,
Let my people go surfing, 2007
Nature's Zen Art, photo credit:
That sounds like perfection of means to
me. But it is perfection of means without confusion of ends.
When an architect we'd worked with took
on a chief architect position within the same company, but a new
business area for him, he said he was comfortable because he knew
VAP would carry him through. He'd used VAP on previous projects, so
was confident that if he went through the VAP movements he'd
practiced before, he'd nail the target. And he did. Because he let
the process lead him, he got the target clear, and then he let the process
line him up to hit the target.
It is pretty neat, being more than a
decade into this, because we hear more and more of these stories
from architects who feel they owe us a nod. Even so,
have to agree with David Christiansen: "I’m not convinced there is
such a thing as a methodology or process that can produce good
create great architecture, just like it is people that create great
software systems.' moi,
That is to say,
VAP didn't create great architects, but great architects are
saying that VAP helped them reach their targets: good, right and
successful architectures. A good solution: technically sound.
The right solution (product, application, system, etc.): it
meets stakeholder needs, where the voice of the customer, the voice
of the business, and the voice of the development team, are taken
into account. And it is successful, in that it is used and is
delivering business value. We often get so heads-down-focused on
doing the product right (or at all), that we forget to question
whether it is the right product. We can't birth or evolve software
solutions without writing (lots of) code and we get so focused on
code as the holy grail, that we overlook the
huge, huge waste in our industry
because we forget that getting the right solution concept takes
work; needs talent and time to incubate.
We can argue back and forth—for
example, one might argue that we need to fail sometimes to create
kinds of gains that we see coming from software. Or we might
argue that what we count as failure, isn't really. It was simply
failure to estimate correctly. Or failure to judge the technology
gestation rate. Or some such failure to establish the right success
criteria. But to me, where our failure costs most sorely is in human
terms. In terms of the software developers who throw their hearts,
brains and serious years of their lives into making something, only
to have it be cancelled before it stands the market survival test.
Put me on a rock face and all the
process in the world won't get me to the summit. A hiking trail,
yes. A vertical drop? Never! I leave adrenalin sports to my
brothers. I got the cautious genes, but more than that, I don't want
to hurt the people I'd leave behind. But hey, it makes me really good
at risk management, for it is not risk that I don't like, only what
would be for me unconscionable risk—the measures for which are
context dependent, and often personal.
Update on Failed Projects
In May 2006, I collected together links
on software failures as well as some links on learning from failure
Now, if I was doing research on failed
projects, I would want to separate those that are cancelled early
from those that are cancelled late, from those that are a market
failure. Those would be interesting and relevant statistics, for it
would better help us track the kind of failures we want to
invest in, from the kind of failures that create waste. We want to
fail fast and cheap; if we're innovating we need to stretch and have
a tolerance for exploration and course resets. We don't want to fail
fast and cheap all the time; but enough to find the solutions
that will win out in the market.
I would also want to track not just how
many projects are late and over-budget, but how well they do, once
they hit the market. I've been close to enough of these "late"
projects to know that the market is the ultimate judge of a
project's success. Being late hits team morale like an avalanche
that is hard to dig out from, and may require digging deeper into
the investors pocket book they may be willing or able to go. But if
they make it past these challenges, how often do they meet with
market success? Does project lateness correlate with failure in the
But, I'm not running those research
projects. Here's an update to what's "out there:"
study commissioned by the U.S.
Department of Commerce's National Institute of Standards and
Technology (NIST) found that software defects cost the U.S.
economy almost $60 billion annually. The study also found that
about 80 percent of development funds are consumed by software
developers identifying and correcting defects. In another study,
The Standish Group reports that canceled software development
projects cost organizations US$55 billion dollars annually."
Business Value of Software Quality, 2004
70%-80% of new product
development that fails, does so not for lack of advanced technology
but because of failure to understand users needs.
Harvard Business Review, February 2007
thing is that there are many out there still using the 1994 Chaos
Report statistics, in which it was reported that some 31% of
software projects are cancelled, as opposed to the 2005 Standish
Group report which apparently found that 23% of projects were
cancelled (I don't have access to the 2005 report, but these stats
are reported in
Why Software Projects Tend to Fail by Cohen Oren, 2008). Did we
get more tolerant and give projects more leeway on schedule and
budget, did we get better at not starting doomed projects, or did we
get better at establishing and hitting the target?
Requirements as Invention
Anyway, the big take-away is
that Einstein is still right. Software projects too often fail
because there is a confusion of ends! And our pursuit of perfection
of means too often detracts from establishing the ends. A perfectly
constructed system is only a perfect system if it delivers
sufficient value to its stakeholders.
Einstein also said:
"If I had 20 days to
solve a problem, I would take 19 days to define it."
No, I don't see that as an
argument for waterfall! I see it as an argument for applying agile
principles to figuring out what the problem is, but I don't believe
we need to use (only) code to do that. Building architects use
drawings, 3D models, and simulations to convey the design to the
stakeholders so the stakeholders can perform thought experiments to
see if the design meets their needs. We need to do more of that.
Requirements don't exist out
there in some extant state that just has to be captured—like cattle
that just have to be corralled.
Requirements are an
invention that come from an interaction between current
need, future (invented) capability, and future need that springs from the
interplay between that capability and the new world it creates. So,
yes, we need to involve the architect in coming up with models and
talking stakeholders through the thought experiments that will help
them figure out what their problem will be, when the system is in
place; that is, what their real requirements are for the fielded
system! (If I think of replacing a paper-based forms system
with an online forms systems, and do not think about the immediate
next things my customers will want the minute they use the online
forms, I have done them and my development team the disservice of
leaving everyone less than
To make it more clear why our
status quo approaches to requirements and architecture lead to
failures, in early "architecture appreciation" courses for managers,
I developed these two slides:
Ok, so that's making a point by
over-emphasis; still, even our best
used-patterns salesman uses that tactic. :) But, yes, too
little requirements and too little architecture leads to a baroque
concoction of best guesses and interpolation.
Links to material that didn't make my
Something along the lines of HelpMatch,
but here and helping people in need today:
This is similar to the Heifer widget
that you can plop on your blog,
and is really neat! Kiva is a
microfinance organization that connects lenders of small loans to
individuals, to help people help themselves out of poverty. Now, shouldn't we be doing this for informal,
person-to-person help networks that enable goods (new and used) and
services to get from people willing to help to where they are
And I hope you'll be inspired to join
the Kiva loan network—do look at the
impact ticker that flashes on the left column! See, for example,
story of Danson Ng'ang'a—read all the way to the bottom, for an
update in this time of political crisis in Kenya. Good and evil
still duke it out in this world, even while we bury our heads in
work. But it is heart-warming to see how rapidly
"technology" (online social networks) is being applied to helping
Another site that is doing something
along the lines of HelpMatch-y ideas is
Give2Network. It makes an
important contribution, though it still focuses on giving help to
"The team at
Give2Network wants to enable people to contribute to their
communities. We want to do our part in giving back by giving away
free and easy-to-use tools that schools and non-profits normally
can’t afford. We recognize that much volunteering revolves around
fundraising (selling and buying needless products) and
time-consuming tasks such as sending emails, soliciting sign-ups,
and communicating with supporters. Give2Network aims to simplify
It is a good place to look for
DonorsChoose.org is similar to Give2network and Kiva. It is
focused on helping public school projects. There are more and more
sources of inspiration and ideas.
'Such stories... thrill [Kiva president] Shah.
"Dude, seriously, this thing is executionally so
ridiculously hard - until it's actually working,
and then it's a flywheel effect," he says,
referring to Jim Collins's metaphor in Good
to Great. "The first crank is really hard,
but by the 100th turn, it's just moving by
itself. And before you know it, people will quit
their jobs and go out and work in Uganda for
at least put up $25 and try to find Uganda on a
Jeffrey O'Brien, "The
Only non-Profit that Matters,' Fortune,
Ready to help build HelpMatch? Money is
much easier to move than goods, but helping with stuff still seems
to be on the table.
Architects and Innovation
In the discussion
around whether or not architects still write code, the point is
often made that architects need to investigate new technologies, and
that is where they still keep their hand in the coding game.
Bill Barr makes salient points, but I would want to caution that
innovation is not just about better means; that is, not just
about developer productivity. Naturally, we couldn't be creating the
complex systems we create today using Assembler! One might argue
that without innovative development technologies, the iTouch/iPhone
couldn't have delivered such innovative capabilities. But innovation
in software development isn't just about retooling or modernizing
software development, deciding whether to hibernate until spring, or
make some other framework or technology selection. It is first and
foremost about innovating to create products, applications or
services that delight customers. But it is also about keeping
talented, passionate developers in high gear, and new technologies
not only (generally speaking) help boost productivity in of
themselves (after the learning curve is scaled), but they also help
attract and/or keep tech-star developers.
That said, the
architect role, especially for architects with broad scope of
influence and accountability, may find themselves squeezed on time
to code. Chris Kempster, in the comments to Bill's post, goes out on a limb that
would come down in flames if
Bill's blog was as hot as
"The idea of IT
architects coding is a joke, it's akin to building architects laying
bricks! Rather than spending time talking with clients and
understanding business issues, laying a foundation with your
technical staff to collaborate, share ideas and capture
enthusiasm... You don't need to code to show leadership and span the
business and technology divide."
Chris Kempster, comment.
I would agree with
Bill Barr, that for project architects and technical leads, being
credible comes from being able to dive in and explain by
example—with an example, and setting an example. But I also agree
with Bill and Chris, that creating the right product requires the
architect's bandwidth, and this competes for attention with creating
the product right. Naturally, we don't want to go wrong on
either—we want right products with right capabilities and
properties, and right properties is a function of both creating the
product right (structurally sound, correct, and reliable) and having
the right target (SMART property requirements).
And since "right"
products or applications don't usually simply exist out there in
users minds, just waiting to be captured and coded up, we need
architects to be working actively to understand what technology
makes possible for stakeholders. For developers and how they build
and assemble systems, yes, that too. ut not only that. Architects
need to actively, creatively, explore how technology capabilities
could be brought to bear so that, for our customers, our products:
"...make their lives the way
they wish they were."
Yes, this is the quote Joachimsthaler (Hidden
in Plain Sight) uses from the inside front cover of the J.
Peterman catalog. I never knew that the way I wished things were had
anything to do with an iTouch, but now that it's here, I wish my
interactions with my iPAQ were that way! How we want our lives, and
the things and experiences in it, to be, is constantly being
reshaped, and it takes innovative thinking not just in the present,
but in the future world that our application or product will exist
in, to really find our opportunity to differentiate—to be "right."
If we ask the
architect to be the design authority, and if we really mean
design authority, we need to give the architect the charter and
the bandwidth to be doing the things that allow innovative ideas to
spark. Remember, "Eureka's" that may in a flash gel a sudden
innovative idea, take hard work, exploration, and ... many showers,
in my case; bath's in
So, what things
should we be doing to allow innovative ideas to spark?
Yes, what Chris
Kempster was saying—get out there and talk with customers
(clients, users, etc.) and understand their business issues
and their dreams, hopes, aspirations, passions, sources of
joy and delight, and concerns, fears, aversions, frustrations or
hassles—focusing on goals, not just actions and activities. For
ideally, many of their actions and activities will be obsolete,
not just automated, if we do our part right.
Booz Allen found that the companies that get the [highest return
on their R&D investments] are the ones that integrate customers and
users deeply in every stage of the innovation process. These
successful innovators involve customers in idea generation, in
selecting the best ideas, and in refining and elaborating ideas.
Keith Sawyer, "How
Customers Drive Innovation," Creativity and Innovation blog,
December 14, 2007
'A major auto company recently
presented its “innovation road
map” for the next ten years to a
group of journalists and car
enthusiasts. As the presentation
progressed, it became
increasingly clear that some
members of the audience were
restless. Finally, one listener
stood up and said, “Many of us
have already built and installed
every single one of the
innovations you say you are
planning to develop in the next
ten years. Wake up and smell the
coffee! Come out to the parking
lot and take a look at what we
have developed and installed in
Eric von Hippel, Breakthrough
Idea Number 6,
Harvard Business Review,
demand ecosystem (every time I use "ecosystem," I think of
David Ing's post), à la Hidden in Plain Sight.
Remember that we bring a technologist's perspective to bear on
understanding the ecosystem. This is not to say we're running
around techno-pontificating, arguing that MySQL is just the
thing for the backend, or whatever our current wicket is.
Rather, we see where technology fits in the daily experience of
our customers; what it does make possible and what it could make
Competitive Landscape which gives a big-picture view of business
context, including the demand ecosystem. It is a good place to
start bringing the perspectives of the multidisciplinary product
concept (or at a higher level, business strategy) team together
on the same page. It provides for structured brainstorming, and
when the participants are selected for diversity of perspective,
can really stimulate the creative foment that produces new
multi-functional teams, with diversity of style and perspective.
Innovation is not, should not be, the exclusive province of
marketing, or business analysts, or architects, or any one
Ten Faces of Innovation makes this point. And we've been
making it with the circles of
innovation model. Though of course, like the circles that
ripple out from a pebble thrown into a pond, each of these
circles speaks to other circles—customers and those who
understand them, technologists and those who have foresight into
technology ripples well before others do, and value partners and
competitors, and those who understand forces shaping the
Read for other
ideas on how to get ideas, and how to get ideas to pay off—for
example, here's a good one:
7 Reasons Why No One Likes Your Ideas.
CIOs, CTOs, COOs,
even manufacturing VP's are getting with the idea that technology is
a key ingredient in innovation-driven business success:
"Management's most crucial investments for factories of the future
won't be the hardware or the software, but in the understanding of
how new technologies provide new options for powering business
John Teresko, Finding
the Next Big Thing, IndustryWeek, March 1, 2008
Yes, apparently John is writing
this from the future!
Here's a neat story about tight
coupling (not software, but I expect you'll be able to translate):
"Henry Ford ... spent roughly 7
years developing mass production
and then another 10 perfecting
it. In the process, Ford built
such a tightly-coupled factory
that, when GM and others
demonstrated the market for
variability in car makes and
models, Ford could not respond.
Changing the design of even a
single bumper created ripples
all up and down the line. 5
years later, to finally change,
all Ford manufacturing
operations were shut down for
six months—laying off 75,000
men—while Ford engineers worked
on a new production line. The
Ford Motor Company never
regained its dominance in the
Creativity versus Efficiency
part 2, September 2007
And here's an example that
illustrates why strategies for scaling (projects or systems) in the
small don't necessarily carry over to scaling in the large:
"Let's say that you
have a recipe for strawberry shortcake that serves four people.
One day you invite
over seven friends to eat this desert. To make it, you simply double
the recipe's proportions.
On another occasion,
you make it only for yourself and a friend, and you halve the
Now, let's suppose
that you invite 50,000 people over for strawberry shortcake. At this
point, the biggest challenges confronting you have nothing to do
with the recipe. These include buying strawberries on the
commodities market, making deals with the teamsters to deliver
enough cream, traffic-flow coordination, and large-scale renting of
tables, chairs, bowls, and spoons."
Roger von Oech,
Beware of Moreness, Creative Think blog, February 5, 2008
Differentiate—or... was that Imitate?
Ok, so I'll X out the name, and
you guess who company X is:
"Why is Strategic Innovation
imperative at X?
It has to do with achieving X's vision:
To be the First Choice of:
* The world’s most coveted talent
Strategic Innovation at Deloitte, The Innovation Index, February
So, did you guess? Odds are
pretty high you're thinking I spilled the beans on your strategy,
right? Ok, X is Deloitte. The
top challenges for CEOs in 2007 ranked as follows:
and steady top-line growth
of strategy by top management
qualified managerial talent
flexibility, adaptability to change
18% of the CEOs surveyed cite
stimulating innovation/creativity/enabling entrepreneurship as their
greatest concern. Moreover,
acquiring/developing the right talent was
rated as the top innovation challenge, according to The Conference
Board report. (Source: CEO Challenge 2007: Top 10 Challenges
reports results from a survey of 769 global CEOs from 40 countries.)
If everyone (or even just 1
in 5 companies) is seeking to innovate by acquiring top talent,
that's going to make for some pretty stiff competition for talent!
It sounds like a zero-sum game, but hey, how about this:
'"Hire naive misfits who argue
with you; encourage failure;
avoid letting client input limit
your vision; and fully commit to
In fact, "failure" seems to be a
dominant theme with just about
every business guru interviewed
the article. At Palo
Alto-based innovation and design
firm IDEO, there is a simple
mantra: "Fail often in order to
succeed sooner." Often, the best
employees turn out to be the
people who might not have been
hired in the first place: "Fresh
perspectives derive from
mavericks with wildly diverse
backgrounds and no
preconceptions who challenge the
status quo, champion their own
ideas, and illuminate the
How to create a culture of
Innovation blog, February 13,
OK, so that was about building
architects and designers; that wouldn't apply to product and
application development, would it? Or, could Steve Jobs be a case in
What I'm getting at, is that the
way we define talent for our business, and the way we go
about innovating in our business, become the starting points of our
differentiation strategy around innovation and talent. This is why
context and strategy maps
are so important—they take high-level bullet points like the
Deloitte vision and tease them out to find the real leverage points
for value creation and differentiation.
World's Most Innovative
this list (from FastCompany) matches your list of the top 10
most innovative companies in the world:
We expect technology to
be tied closely with differentiation at the likes of Google and
Apple and Nokia. But why was Nike in the list? Social networks, on
and offline. But online. And so it goes.
Google has gone after the
hire-the-best-talent strategy and done very well with it. But Google
created an innovation ecosystem. (That's even better than ecosystem
on its own,
huh Erik? **) No really. Google created the
physical environment, the hiring practices, the performance
monitoring and reward system,
the time, etc., etc., and a mass of Google groupies
who think Google is cool. Google's talent strategy works, because
Google is doing work that top talent wants to do. But that is not
the whole story. Google has created an innovation identity, and top
talent whose personal identity aligns with that, are attracted to
GE being in the Innovation Top
Five is important, for it does a lot to dispel any myths we might
hold that elephants can't dance. I watched an interview with
GE CEO Jeff Immelt, and he
said something along the lines of "if
you want a front seat on history, work for GE, not some start-up"
(I'm paraphrasing from memory).
Gosh, I sure hope GE figures out
how to make wind and
solar energy as de facto on our homes as satellite
dishes—providing green solutions to the energy problem in developed
countries not just
developing countries! So,
residential wind power is gaining momentum. Hollywood could do
its part—put a
panel and/or wind turbine on every house in every movie that is
produced over the next year (and why stop there?), so that we get
the vision firmly implanted; we could leave this planet
better off than it was when we entered it! Isn't that what we all
want, in some small or big way? Well, then, let's not kill the
environment while we go about making our mark on the world!!
** Here's a
litmus test for architects: you're a good candidate if "innovation
ecosystem" has you feeling antsy, but even so you are drawn to it.
This test indicates that you are able to traverse the business world
without being tagged an imposter, yet you are, in your heart and in
your true allegiance, an engineer. Eh, I just made that up so I'd
Architect as Time Traveler
Two things I really like about
working with Dana Bredemeyer:
I told Dana about the gavel I've
been pounding: requirements aren't simply extant, waiting to be
captured, or even "discovered." They are invented, or at least, they
should be—and are, when innovation happens. There is
an interaction between needs/goals/desires that exist, and ideas for
meeting those needs, which changes the concept of the needs and the
range of possible "solutions" to them.
So the architect is, in Dana's
words, a "time traveler" who must
go into the future, invent the
problem/solution that will deliver delight and value in the future
when the system is delivered and it is interacting with the new
world it and other systems and processes have created, and all the
new expectations these systems and interactions have created. One agilist may say the best way to do this is to incrementally evolve
the system, allowing self-organizing system principles and Darwinian
evolution (what is that called, when it is evolution in an economy
rather than biological evolution?) to have sway. But this agilist (moi)
says we can do better than that, because we evolved to have a
prefrontal cortex, which though not a crystal ball, does let us
imagine a future and take steps towards creating it.
When creating the iPod, it
wasn't enough to think about playing music on a device more portable
and sexy than a CD player. A whole new world had to be created
around licensing, uploading, downloading, managing digital rights,
and ... a truck-load of other stuff I haven't hallucinated. The
whole experience had to be thought through, to be created. First in
the mind's of men and women, yes. But the ideas had to be
iteratively explored, to understand what it will take to make the
new ecosystem (sorry Erik) not just viable but compelling; to create
an experience that delights. This iteration doesn't have to proceed
at the pace of cutting code; we can speed up the Darwinian evolution
of our inventions using models and other techniques.
It sounds all very well put like
that, no? But do we have practical ways to make real on this kind of
innovation, when we aren't Apple and we don't have a
visionary-extraordinaire like Jobs? We use Competitive Landscape
maps, Technology Roadmaps and Projections, Scenarios (à
Art of the Long View, as opposed to OOAD instances of use
Desired State Interviews to help move us into the future. These
are what I've found time and again to be great Pareto tools (i.e.,
20% effort for 80% value, as compared to other techniques), which is
not to say I don't use other techniques as and when I see the need
to borrow or invent to add to early envisioning/concept-germination
iterations of the
Visual Architecting Process.
If we divorce the activity of
"inventing the problem" from the activity of "inventing the
solution," we break the innovation cycle and the necessary interaction between
problem concept and solution concept which redefines the problem
concept. (We need better terms than "problem" and "solution" here;
but you know I don't mean we're creating problems, but rather
opportunities to deliver value.) So the place we have to
start, is making the partnership work. And I don't just mean
marriage counseling between marketing or business analysts and
architects! For one thing, given the right architect, I'd want him
or her to lead the whole design—the invention of the problem and
the invention of the solution. A team, preferably a diverse team, is
needed to do this, but having someone end-to-end responsible for
leading the design lends critical accountability, for pie-in-the-sky
dreams are not what this is about.
And for those of you who are
pooh-poohing all this as only relevant to greenfields situations and
disruptive innovation, let me quickly say I think that it is
important to do our "time traveling" when we're marching down the
sustaining innovation path. Sure, we're more constrained by the past
when we're creating incremental improvements, and we don't time
travel as far into the future, but we still need to be inventive,
creatively interpreting expressed needs and goals in terms of system
Requirements and Innovation, by Ruth Malan, July 28, 2006
And how do you like this for
map? Hmmm! Well, I guess it takes into account diverse
perspectives, and that's good... And the format is neat! Like, let's
get off at the "attention economy" stop (on the green line) and
explore that for a while.
Tags and Google Reigns—or Not!
I haven't bothered to use tags
because with a Google search restricted to my domain, I can quickly
find all references to any word or phrase on my site, and I
don't have to do any work! In this regard, Google has a serious edge
over Yahoo! Try, for example, a search on
on Yahoo and then on Google. Yup, Mi-Yahoo has some work to do. But,
but... I have to report, I just Googled
"Fridays at Google"
site:www.ruthmalan.com and got zip, nadda. I Yahoo'd the same
search term and got exactly (and only) the piece I was looking for.
And there's further irony to it, but you'd have to
read the piece.
My Influence Dashboard
This report from Amazon for the
last 2 months will clearly show you that my influence is... well,
Reepicheep comes to mind... a valiant mouse but for all that, hard
to hear above the din... (Don't worry, if you don't recognize the
reference, you will in a few months after
[careful—mute first—this is a noisy site] comes out... ouch!
Didn't I give you a Koosh ball for that?)
Hmm, well, at least
I got 21 people to look at
The Wheel on the School! Perhaps they were so excited they
decided to run over to Barnes and Noble and buy a copy right then
and there... Either that, or they thought I was bananas bringing
kids stuff into the work place—serious credibility hit, and all
that. But really, when innovation is the battle-cry of the day in
the corporate wars on consumer pocket books and talent, this vision
story is quite illuminating. It does the visioning bit so well, and
then there's teams, of teams, working together like cogs in an
Oh well, never let it be said
that I don't take risks, even if you won't catch me scaling a rock
[2/27/08] Speaking of which, let
me be perfectly clear here: I am highly recommending
Let My People Go Surfing: The Education of a Reluctant
Businessman, by Yvon Chouinard. There
are moments when Yvon strikes me as a little egotistical and
self-serving ... like when he says "doing
risk sports will create stresses that lead to bettering one's self."
Um, Yvon, some of us can apply the Socratic method to ourselves
without being in personal peril. It's called introspection and
I don't have to be facing death on a Himalayan peak to examine my
life! I don't even have to be taking a hike. Oh, I should be...?
Now I know, I know,
if you had to read everything I got excited about (plus everything
you're excited about) you'd have no time to do your
architect job! But, one of the things that often comes up in "how to
be more innovative" advice columns is read outside your normal box.
Patagonia may seem outside the box, but when you see how Yvon uses
philosophies and principles to lead the highly individualized
Patagonia employee base, you'll see that it is all quite relevant,
even if it needs some translation. But, you're an architect. You
translate all the time. And innovation is mostly about translation.
Even ground-breaking inventions are often about translation—using a
model that exists in some other space, like in nature.
Nature! Yes, that
reminds me. Yvon makes a strong case for pulling out the stops to
save the environment from its rapid slide into irreparable
devastation. If you're hiding your head in the sand like the
proverbial ostrich I've been emulating, you'll hopefully find Yvon's
message a good wake-up call. It's not just about our carbon
footprint (that too, is crucially importantly) but about how broad
and devastatingly we are destroying this planet—beyond it's
capacity to regenerate, despite how miraculously adaptive this
planet is. Yvon tells of this insect that has, just since WWII,
evolved this capacity to shed its legs when it comes into contact
with pesticides! Yvon is using that to make a point about stresses
being vital to evolution, and the rapid adaptation that happens in
response to stress. So stress is important—to businesses, not
fragile river ecosystems and non-renewable resources! We use the
Competitive Landscape this way, to help produce a shared sense of
unease with the status quo that builds to a shared sense of urgency
and passion to change. We need to do that with our business and our
personal lives, so we change what we do, and impact the planet in
healthy, life sustaining ways. Everything we strive for now amounts
to NOTHING, if our children have to suffer on a dying planet when
they reach the age we are now!
It would be great
if coalitions of the world's super-wealthy were to lead an effort to
buy, for world preservation, as much as possible of the most fragile
lands on earth, and put it in a world trust, so no one nation can do
damage to it. But we have to start doing what we can, personally and
in our businesses, to reduce our carbon footprint and our pesticide
and chemical footprint. Has our generation done more damage than all
the generations that preceded us, put together? It seems that way.
Ultimately, I'm afraid, history will show that is a bigger scourge
to bear, than the scourge of initiating WWI or WWII. And we, each of
us, is culpable;
but I am, in bigger part than most! So, change I must! And for
my penance (if you'd just read Chouinard...), I must urge us all to
To show you just
how superb and relevant Yvon Chouinard's
Let My People Go Surfing: The Education of a Reluctant
Businessman is, I've quoted above and
beyond the usual amount of text in what follows, but it is to urge
you to buy or borrow and read this book (the purple
highlights are mine):
psychologists who specialize in organizational development tell us
that Patagonia has a far above average number of very
independent-minded employees. In fact,
our employees are so independent,
we're told, that they would be considered unemployable in a typical
We don't hire
the kind of people you can order around, like the foot soldiers in
an army who charge from their foxholes without question when their
sergeant yells, "Let's go, boys!" We don't want drones who will
simply follow directions. We
want the kind of employee who will question the wisdom of something
he regards as a bad decision.
We do want people who, once
they buy into a decision and believe in what they are doing, will
work like demons to produce
something of the highest
possible quality—whether a
shirt, a catalog, a store display, or a computer program. How you
get these highly individualistic people to align and work for a
common cause is the art of
management at Patagonia.
Since we don't
order our employees around, either they have to be convinced that
what they are being asked to do is right, or they have to see for
themselves it's right. Some
independent people, until the point they they "get it" or it becomes
"their idea," will outright refuse to do a job. Or worse, you get a
passive-aggressive response so that you think the job will be done,
but in the end the person just won't do it—a more polite but more
costly form of refusal.
In a company as
complex as ours no one person
has the answers to our problems, but each has a part of the solution.
The best democracy exists when
decisions are made through consensus,
when everyone comes to an agreement that the decision made is the
correct one. Decisions based
on compromise often leave the problem not completely solved,
with both sides feeling
cheated or unimportant or
worse, as in the biblical example of Solomon,
cutting the baby in half
to settle the dispute between two harlots claiming the same baby.
The key to building a
is good communication. A chief
in an American Indian tribe was not elected because he was the
richest or had a strong political machine;
he was chosen chief because of his
oratory skills, which were invaluable for building consensus within
the tribe. In this information
age it's tempting for managers to manage from their desks, staring
at their computer screens and sending out instructions, instead of
managing by walking about and talking to people. The best managers
are never at their desks yet can be easily found and approached by
everyone reporting to them.
offices support these ideas. No one has a private office in our
company, and everyone works in open rooms with no doors or
separations. What we lose in "quiet thinking space" is more than
made up for with better communication and egalitarian atmosphere.
Animals and humans that live
in groups or flocks constantly learn from one another.
you look to hire management, it is important to know the difference
between leaders and managers. ... Managers have short-term vision,
implement strategic plans, and keep things running as they always
risks, have long-term vision, create the strategic plans, and
The best leadership is
by example. ..."
The only thing I would change in
the above, is the wording "art of management"
to "art of leadership." The foxhole bit
should remind you of my
Command and Control bit which, of course, you've read at least 3
times by now. What, you didn't follow
my links? What kind of good follower are you, anyway? Oh...
you're independent minded... So, didn't Yvon just say "the best
leadership is by example"? There's a time for leading and a time for
following, a time for asking and getting out of the box, and a time
for drawing to consensus. Being an independent thinker doesn't mean
you never agree with anyone else, and always question
(read resist) direction!
I drew that "cartoon" in
something like 1997, while working with the lead architect and a
team of architects that needed to be aligned (just, not mechanically like
wheels)... it would serve just as well if we replaced "architects"
with "engineers," we just couldn't show it to them.
2/27/08 Coupling and
A couple of days ago, Dana
Bredemeyer mentioned Chuang Tzu's "How to Govern" and in particular,
Butcher. One of the most famous parables in
Tzu concerns Cook Ding, a skilled butcher whose talent was noticed
by Lord Wen-Hui.
When asked to explain his skill, he replied:
"Sire," replied the
cook laying down his chopper, "I have always devoted myself to Tao,
which is higher than mere skill. When I first began to cut up
bullocks, I saw before me whole bullocks. After three years'
practice, I saw no more whole animals. And now I work with my mind
and not with my eye. My mind works along without the control of the
senses. Falling back upon eternal principles, I glide through such
great joints or cavities as there may be, according to the natural
constitution of the animal. I do not even touch the convolutions of
muscle and tendon, still less attempt to cut through large bones.
"A good cook
changes his chopper once a year, —because he cuts.
cook, once a month, —because he hacks.
But I have had this chopper nineteen years, and although I have cut
up many thousand bullocks, its edge is as if fresh from the
whetstone. For at the joints there are always interstices, and the
edge of a chopper being without thickness, it remains only to insert
that which is without thickness into such an interstice. Indeed
there is plenty of room for the blade to move about. It is thus that
I have kept my chopper for nineteen years as though fresh from the
I come to a complicated place, I size up the difficulties, tell
myself to watch out and be careful, keep my eyes on what I’m
doing, work very slowly, and move the knife with the greatest
subtlety, until – flop! The whole thing comes apart like a clod
of earth crumbling to the ground. I stand there holding the
knife and look all around me, completely satisfied and reluctant
to move on, and then I wipe off the knife and put it away.”
Too far from XML for you? Well,
I thought if I mentioned Dana Bredemeyer recommended it to me, I
could get away with it...
The title to this section hints at my
interpretation in the context of architects. It takes experience and
artistry to find the right lines of cleavage in a system, but if we
pay attention, we do, and it is satisfying to stand back and know we
did right. When we find the natural abstractions that lend
themselves to defining cohesive components (services, subsystem,
modules), and the natural mechanisms that provide the interstitial
matter that makes the system fluid, flexible, yet resilient, then,
why gee, we have the bullocks that come apart without dulling the
butchers knife... I don't know... maybe we should just let this one
rest in the kitchen, as a lesson on how to cut up chicken and ducks
(since we prefer not to eat mammals)?
That is the power of the piece—you
make what you will of the lesson. I've read chapter 3 of
The Wheel on the School in two workshops, and in a third I
asked for a volunteer to read it then talk about it. (I go there in
Role of the Architect workshops, where I establish permission
to tackle more of our confining preconceptions.) One of these times,
an architect asked if I thought the author (DeJong) intended the
piece to be used the way I use it. My response was that it doesn't
matter; what matters is what we learn, what pieces fall into place
for us. Because I've learned that some of the most important lessons
are the ones that, once we recognize them, are obvious; they were
staring us in the face but we just didn't see them, just didn't fit
all the pieces quite together, and then suddenly someone or
something makes it all go ca-ching and we have that epiphany feeling
and everyone else goes "duh" yet they didn't see it that way until
you expressed your flash of insight! Anyway, if you weren't
reading along last September, I wrote about
wondering lessons from The Wheel, as well as
wondering at Google that are both relevant to the innovation
thing I've been kicking around this month.
2/27/08 Your Action Required
Can you please (each and every
one of you) add the Resources for Architects website (www.bredemeyer.com)
wikipedia page on software architecture under External Links.
I once added it only to have it be removed, but I don't think it is
fair to have Grady Booch's Handbook (that is promised but not here yet) or FirebrandArchitect's
www.Software.Architectures.com and so forth be allowed, if THE
SEMINAL original pioneering architecture website (dating all the way
back to 1998) and still one of the most USEFUL resources for
software architects out there, isn't allowed to show up!!! Hmmph!
Thank you for your support! :)
Don't think someone else will do this...
Ackoff's Idealized Design
I picked up Dana's dog-eared
copy of Ackoff's
Idealized Design and started to read it. So,
I have to tell you, Ackoff is quite "allergic" to the notion of
time traveling into the
future to envision our desired state. He contends we need to formulate
the state we want now. Ackoff argues (much like many Agilists)
that we aren't good at predicting the future, and concludes we
shouldn't design "in" the future. I think it is a matter of how
Ackoff is framing up this "going to the future." If we keep
ourselves grounded in what we know and can find out about
needs and what is happening around us in terms of technology
capability and user expectations, we're not flying above the ozone
to apply evident trends and patterns. Two years ago, it was our
strong intuition that social networks was the way to move forward
with HelpMatch; today it is self-evident. But today it is late to be
entering the game!
We can ask people to "move into
the future when the system is delivered" and think about how things
"are" now that the system is in place and delivering value, or we
can ask people how they would like things to be today. In both
cases, we need to state two important rules of the game:
Must be feasible and
viable: We need to restrict ourselves to what is technically
feasible and operationally viable, so we remove the Utopian
dreams from scope—no telepathy or "beam me up Scottie"
transporters, no flying cars. (Oh no, can't I have flying cars?
Or at least, wind turbines on every rooftop, you know, next to
the satellite dish?)
See past the obstacles:
We need to free ourselves from the obstacles of the present.
When we design from the present, we want to solve problems we
currently face—so we tinker and tweak, but don't make the
strategic moves that would change our positioning.
We have found that asking people
to think of "being" in the timeframe of the system delivery, rather
than now, frees them up from that obstacle-focused rut we tend to
be so stuck in. But if our stakeholders have Ackoff's orientation to "time
traveling" don't call it that! Don't let the name of a thing
get in the way of what is important.
What is important is to envision
the system (organization, product, whatever we're setting out to
build or improve upon). And freeing ourselves from the shackles of
present day-to-day hassles is one piece of this. The other piece is
being inventive, though not unrealistic. And we need to think of the
system as a piece of bigger systems. It will impact and be impacted
by other systems and we need to think through and do what we can to
foresee the implications and hidden assumptions that will otherwise
surely surface to bite us.
In Ackoff's frame, we try to
understand the desired state our stakeholders want based on what we
know now—but we can't have it now. We can't change instantaneously
and get the desired state we want now, today or even next week; not
if the change is the kind that saves us from "the mess" (Ackoff's
term) we're in. So we have to do some work to think around the edges
of what we know, to find out new things, look at trends and
patterns, look at other geographies or industries, look at our
markets with a different lens, stretch what we know. You know the
adage "If we keep doing what we've always done, we'll get what we
always got"? To that we need to add, "If we act on what we already
know, we'll keep doing what we've always done, and get what we
always got." So we need to find out new things. Call it going to the
future, call it staying in the present, or call it whatever. Just
get out of the box!
With HelpMatch, you don't go far
down the path of envisioning before issues around fraudulent use and
trust come up, so then you work on addressing trust and that brings
up social networks. And so it goes. Systems have a ripple effect. We
have to think enough of this through, to figure out whether we have
a viable problem/solution concept pairing. Otherwise, we're just
saying we have no recourse but to succumb to the winnowing of
Darwinian selection processes. Of course, I believe we can be more
intentional than that. No, we can't predict the future. Yes, we can
shape it. If we didn't believe we could create at least partially
self-fulfilling prophecies, we would not have much reason to do
Idealized Design! We'd just take any of several possible obvious
next steps, and let the market tune us up or tune us out.
2/28/08 Spam crime
Did spammers decide to take
America down today? I received upwards of
8000 spam emails just today! This is
more than 4
16 times the usual spam load,
and more of it has escaped the filters than usual today. Has anyone
calculated the cost to the economy?
So, sorry if I deleted your
email hidden in
acres of spam today! ...