1/15/09 Visualization and Visual Thinking
Verbal thinking tends to be linear, while "picture thinking" allows
for non-linear expression and thinking. So, you can see
relationships and interactions, and perform thought
experiments, for example, changing the relationships and interactions.
I read Sharky's post and
watched these Kermit clips on YouTube
(by way of Garr Reynold's
Presentation Zen blog):
and I thought "Hey, visualizing software and visualizing jazz are
not all that unlike!" Now, I ask you, where's the splot in UML? What
would it mean? Where have you been? "Splot happens here," of
course! And they didn't ask me to represent HP on the first
version of UML! Outrageous!
1/15/09 Mark your calendar: This Journal Turns Three SOON!
Ok, for all of you who forget anniversaries and birthdays, this
journal turns 3 on February 3! Last year,
I reminded everyone, but
still no-one took the opportunity to say "You are a model of grit
and determination" ... or "I love your wry sense of humor—I
don't understand it, but it helps me go to sleep feeling grateful
... that I'm not you!," or ... whatever! Grin.
Anyway, with three years of entries stacking up,
I thought this would be a good opportunity to highlight some of my
favorite bits and pieces:
Favorite line:
We aren't mere windsocks
responding to the direction of the wind; we make wind!
Yes, my trademark double entendre.
In context:
One other flaw in much
of the "we must respond to a changing world" thinking is that it
neglects our impact on the world. We aren't mere windsocks
responding to the direction of the wind; we make wind! We change the
course of history, in small and big ways, with what we create. We
change expectations about what is possible. We interact with
destiny, don't just simply bow to it. Though, to be sure, we ignore
these forces at our peril. But ignoring our role in shaping
expectation, shaping the world into which our systems will fit, is
just as one-sided as blindly expecting users to force-fit our
product offering to their needs. The world of pragmatists is the
world of balance, the world of tradeoffs. This is just as true for
the process we adapt to fit our needs as it is to the products we
generate thereby.
moi,
August 2007
Favorite quote:
"Listen, are you breathing just a little and calling it a life?"
Mary Oliver
Book discovery that most excited me:
The Wheel on the School [A $7 book that puts together the
most important lessons of field-shapers like
Kotter,
Coplien and Harrison, and more, has to be an exciting find—even
for those who don't have a child-like sense of wonder, it's good
value for money! There, whether you're a creative awe-struck seeking
sort or a down-the-line pragmatist, I've got you on that one.]
Please feel free to celebrate my ...tenacity ... by telling me why
you stop by, or ... whatever.
I
won't promise to put all your celebratory words on this page,
because... well, frankly, I know you're busy... yeah, that's it.
[It's not that I'm forestalling public embarrassment at the deathly
silence in response to my unabashed fishing for compliments. Nah,
that can't be it... Grin]
Anyway, siyabonga (or thank you, danke schön,
merci, muchas gracias,
etc.).
1/16/09 To Redesign or Not to
Redesign, That is the Question
Arnon's post pointed me to "Uncle Bob's" post on
The Big Redesign in the Sky. It's worth a read for it is witty
and holds wisdom. But allow me to paraphrase:
Don't redesign because you won't be
disciplined on the redesign and will just end up with a duplicate
mess, slower. The only answer is to be disciplined about cleaning up
the mess you have, today and every day.
We have no discipline, yet the answer is discipline...
Ok, so how much of your legacy code base is obsolete?
Technologically, and functionally? How much is a structural disaster
zone? Have your code bases diverged so much that the only recourse
is to maintain n variant code trees? And you should
never redesign?
"Extreme positions are valid in
extreme cases. And only then."
moi, 4/12/08
(If you don't know me, the last part is irony.
Satire in a nutshell, my dear Watson. Satire.)
Another kind of extreme position is "the whole shebang has to be
redesigned at once." Sometimes this is true. Like, the hardware
platform is being evolved to embrace technological innovations, and
the change is
so radical that the software platform for the product family
has to roll too. Or development environment support on a new
platform provides so much greater productivity that rolling the
system is indicated (in the medical sense; grin). But the architect
is a pragmatist. Pragmatically, the architect needs to weight the
options. Redesign or refactor; partial or radical.
I live in the software world, so that is the world I know. I don't
know if other people are so predominantly like this, but we sure do
like binary logic!
Black and white, either-or options.
And checklists!
And in both cases, I get uncomfortable. We need to strive for
simplicity. And we need to leverage the knowledge and experience of
others. And we need to think about the demands of our
situation!
If you want some bold advice, it is this:
For systems that the competitive advantage of your business depends
on
-
develop your system incrementally, actively
simplifying, refactoring, cleaning up, redesigning as you go
-
obsolete your system, redesigning and
rebuilding it from scratch every three to five years
Why? If you don't, a competitor will! But don't—please don't—just
rebuild a cleaner version of your old system. That is where the
whole rebuild trap lies. Build a new system—build the system
a start-up would build to knock the socks off your legacy-bound
system and trounce you in the market!
"The Stone Age didn't end
because of a shortage of stones!" Al Gore, live broadcast on
7/17/08
Every build from scratch project has to look forward, not
backward! If looking forward, you see that you need to bring the
past with you, well and good. But chances are, where your customers
are going they're not going to care nearly so much about your legacy
as you would like to think! Yes, they'll have a point of resistance
but the ever changing competitive context will push them past that.
I learned an important lesson from Bounty paper towels: when the
rolls with closer perforations came out, I was frustrated at how
hard it was to get a "full-sized" towel. But very quickly, I adapted
to using just enough paper towel for my emergency. Now I even tear
my half-size strips into quarter size strips, if I don't need the
extra paper. The product led the consumer, but in a context of
growing consciousness of the value of green. Bucky Fuller's
technology gestation rate is important to understand, but has to be
taken in the context of context! If your part of the world is
moving at avalanche speed, expect the gestation rate to be swept
along with it!
Remember though, bold advice is only that—bold advice. Advice to be
taken advisedly! The source may count, but your judgment is why you
have the big title—aRchitect! Reason about and rationalize your choices against
value and challenge and risk, now and taking into account the future
you are leading your organization and its products and
services into.
Your legacy represents a huge investment, a wealth of intellectual
property, and it is worth working hard to keep that vital and
viable, investing in ongoing system health, structural integrity and
value renewal. But it is also entirely sunk cost if it is going to
be obsoleted in the marketplace, and it is better, though hard—hard
to the point of most unlikely— for organizations to obsolete their
own systems. Rechtin's
Why Eagles Can't Swim is a great reference, as is
Christensen's
Innovator's Dilemma.
From scratch "next gen" efforts are very risky, and highly prone to
being cancelled before they have a chance to mature and prove
themselves in the market. Splitting resources between sustaining the
"legacy" -- or the current system under (d)evolution -- and the next
gen system is hard for the organization to sustain, next gen system
invariably cost more and take longer than anticipated and often
doesn't fare well under scrutiny when belts have to be tightened...
There is a lot to weigh. But the architect working with the
management team has to do this on a case by case basis. No easy glib
"don't redesign" or "redesign every 3 to 5 years" is going to be
universally "right." ARchitect; identify opportunities, experiment
enough to know which are most promising, and show incremental value,
looking to leverage existing investments but being watchful lest
legacy investments are just plain encumbrance given where the market
is headed.
As for checklists, I touched on the topic of
checklists here,
but I had a bad link (and no-one pointed that out to me; I highly
recommended it, yet no-one tried to follow it??? Grin). Anyhoo, I
fixed the link (and added one), and it's well worth a hop—great
stories/analogies.
Structural Analysis Tools:
Joel on Software also has a (characteristically) polar take in "Things
You Should Never Do." He makes (characteristically) good points,
colorfully. But I try to remember "never say never" (grin). Again,
aRchitect--apply Reason and good judgment! The picture is generally
complex, with lots of factors to weigh--whether we are deciding what
to do going forward, or trying to interpret the lessons history
teaches. For example, according to
this
wikipedia entry: IE 5.0 was released in March 1999 and IE 6.0
was released in October 2001 -- or 2.5 years between releases.
Netscape 4.0 was released in June 1997 and Netscape 6.0 in November
2000. So simply pointing to 3 years doesn't provide the insight we
need. We need to know if IE 5.0 leapfrogged Netscape 4.0
sufficiently to garner the market and buy Microsoft the leeway to
spend 2.5 years on its next release... or was it something else,
like Microsoft's market presence?)
1/16/09 Putting Me Into It
Well,
at the kids urging, I got to see Marley and Me tonight. I had
more fun with it than I anticipated. I just loved John Grogan's
boss! Imagine—supporting a writer who puts himself into his writing,
is funny, all that... I'm laughing my head off. No, really, I am.
Ah, the power of context.
They say that the
definition of insanity is doing the same thing over and over and
expecting a different result. But isn't the definition of hope
getting the same result over and over and still expecting something
else? At any rate, my
command and control piece comes to mind. Again. The kids still
don't close the door when I ask them to. And yet I still ask them
to. After all this time. And I still hope that my values will
somehow stick when my behests do not... Insanity or hope?
Or, is that "willing suspension of
disbelief"? You know, it's how we get through life! And it's what we
ask of our developers! And managers.
1/18/09 Speaking of Favorites!
I just read Charlie Alfred's latest post,
The Seven Deadly Sins of Product Development, and I have to say,
of all Charlie's essays and posts to date (and they are all
excellent and absolutely on-point for architects), this is my
favorite! Well done Charlie! I most heartily recommend it!
1/18/09 Architect Jobs
Well, there are openings for architects
in California, at least.
Southern California Edison is hiring 3 architects and
Intuit is moving into the cloud apparently, and
with it, also creating 3 new architect positions:
Software
Architect
Req 67357—Mt. View, CA
- BI/CRM Cloud
applications, Oracle, Hibernate, J2EE
Cloud/Virtualization Architects—Mt. View, CA Network
Req 65738 & Edge Computing
Req 66216 —Mt. View, CA
-
Cloud/Distributed/Grid computing knowledge, Virtualization exp.,
design exp.
1/19/09 The Power of Context
As I have come to see it, one of the most important things the
architect does is set context for the development team. In more
complex organizational situations, like large development projects
or distributed teams, it is important to do this explicitly for
organic, ad hoc communication, by itself, is too hit-or-miss for something this
vital to project health and success.
Context—business and product context, and technical context—is
what enables the team to be empowered, because
context—appropriately and adequately set context—provides the
means for
alignment not just on surface objectives and priorities,
but on a deeper understanding of intent and meaning.
So what do I mean by context? On the business side, I mean the
strategic vision (vision, strategic goals and roadmap), and an
understanding of what makes that vision make sense for the
organization or product—a rich picture of the competitive landscape
and value stream context. Now, this is not typically the bailiwick
of the technical person. But we do need to convey this context, and
motivate why we are doing so. To empower decision making, we need to
share enough of the context so that decisions line up with the
differentiating value propositions of the system, product or
service. Yes, the architecture translates business/product
strategy into technical strategy. Still, so many decisions are made
during development, that sharing the business/product context
directly, as well as through the architecture, helps achieve
alignment through the myriad diverse decisions that are made
throughout the project.
On the technical side, I mean the architecture creates technical
context. Architecture strategy, and the conceptual, logical and
execution (physical) architecture decision set and the
considerations that make these decisions make sense, create the
technical context for design and development decisions. All context
does not need to be created at once, nor can it be. But as this
context is understood and assimilated, created even, it needs to be shared.
Agilists emphasize talking about the system over documenting it.
Talking about the system is for those who are part of the
conversation at that point in time, and it has strong advantages in
participation and so energy, as well as being able to dynamically
shift the conversation to address uncertainties, ambiguities,
questions, and whatnot.
Writing about the system is for those who will read what is written,
now and into the future. You can guide and direct the flow of
attention, and the reader can backtrack to go back over a point that
needs more of their attention to grok, for example. And the writer
can go back and fill in, clarify, amend.
Recorded conversations, both the structured presentations and
unstructured reviews, provide a mechanism to pass some of the benefit of
the communication into the future. This is important to do but can
become an unstructured time-consuming mass. Creating a recommended selection of video
clips and readings is a good
way to bring new team members on board, supplementing live meetings
and reviews (for these shouldn't be waived away just because there
is more of a bit trail than just code).
So it is still important to write about the system. It is often
easier, for those whose style meshes well with reading, to navigate
a document (or set of documents, tailored to addressing scoped
concerns). And the act of writing also helps the architect get more
clear about what she or he wants to convey. It helps to prioritize,
to think things through more deeply, to explain, and... more that
I'd write but all the project demands of today press upon me.
Wry grin (it's what we all say... we'd write more, but project
demands press upon us...)
1/19/09 Mobility Buzz
Cutter wants your help putting it's finger on the pulse of the buzz
around "Mobile EA":
"Mobility offers advantages for the business,
thanks primarily to two characteristics: location independence and
personalization. Cutter Consortium’s latest survey investigates
mobility trends in organizations, including changes to the business
model, adoption of mobile technology, and the social impacts of
mobility. I hope you'll let us know your opinions by participating
in our research.
Receive your immediate, complimentary copy of the Cutter Consortium
article Mobile Enterprise Architecture: Model and Application,
when you complete our survey on Opportunities and Challenges around
Mobile Technologies, at
http://www.keysurvey.com/survey/236483/e7f7/
About Mobile Enterprise Architecture: Model and Application
A comprehensive Mobile Enterprise Architecture
(MEA) treats mobility not as an add-on to the existing business
processes but as an integral part of the enterprise architecture. The
MEA enables an enterprise to achieve the advantages from mobility while
reducing the risks associated with its implementation. You will learn
what constitutes an MEA and the value of creating such an MEA for an
organization. You will investigate the advantages and limitations of an
MEA, creating and using a mobile application development platform, the
MEA roadmap for transition, and the mobile service-oriented
architecture."
Email from Cutter Consortium, 1/18/09
1/20/09 A HUGE Day!
Peter K. from The Netherlands wrote this on his Bredemeyer
Resources for Architects
mailing list sign-up:
"Your site is a bright one and
an eye opener for me as well."
Can words really make a difference, and why do we expect so much
from Obama today?
Kennedy said:
"we choose to go to the moon in
this decade and do the other things, not because they are easy, but
because they are hard, because that goal will serve to organize and
measure the best of our energies and skills, because that challenge
is one that we are willing to accept, one we are unwilling to
postpone, and one which we intend to win, and the others, too."
We choose to go to the moon, John F. Kennedy,
wikisource
Gus Grissom heard these words, and was inspired and determined to do
it. He never made it to the moon, but his role in the space program was
forceful. He was the driving "customer" who the user experience was
so shaped around, the
spacecraft was too small for other astronauts!
Words do make a difference! A leader's rhetoric can inspire a
nation, a world even. And these words of inspiration align, motivate and empower
action. This is a day to go down in history, and much, perhaps too
much, is expected from this speech and the man who will make it. But
he is a leader, and leaders are great because of the greatness, the
great contributions, of all the people they inspire and align.
1/20/09 Moral Leadership Demonstrated by... Counterexample!
The board at our Montessori school voted to not show the
inauguration (swearing in and speech) today, because they didn't
want the kids being on either side of a "my guy won" thing.
One of the parents, a political science professor at IU, responded:
"That's the text. But what's
the context?" The context is that this is a
historic moment from so many perspectives. We're in a recession and
the general global mood is very depressed. Everyone expects Obama to
speak to this crisis, and if that were the only thing, it would be
big enough because a financial crisis of this magnitude impacts
everybody! And this
is a bigger moment even than that.
It is a momentous moment in the US civil rights movement. Moreover,
this is a global moment—a moment when the child of a world
union, a union of an African and an American—is sworn into not just
the top position in the US but also a position of global leadership.
Yes, this is a big moment. It is bigger than America, and children
will be watching this moment LIVE around the world. This is a big
moment in our time, in our country, in the world, and in all of
history.
Well, back to my various and varied ongoing projects. Deadlines
loom.
1/20/09 Moral Leadership Demonstrated—by Example!
Wow! An
inspiring speech delivered to this nation, and the world. We
joined friends and watched the Inauguration in a rather festive
atmosphere, so I went back and reread the speech, and it gets still
better with concentration. For it is a speech that is full of wisdom
and hope, and a call to imagine and to do.
"Now, there are some who
question the scale of our ambitions — who suggest that our system
cannot tolerate too many big plans. Their memories are short. For
they have forgotten what this country has already done;
what free men and women can achieve when
imagination is joined to common purpose, and necessity to courage.
... The time has come to
reaffirm our enduring spirit;
to choose our better history;
to carry forward that precious gift, that noble idea, passed on from
generation to generation: the God-given promise that all are equal,
all are free, and all
deserve a chance to pursue
their full measure of happiness."
Barack Obama, 1/20/09
Leading in to the Inauguration, a commentator said "Today,
history will be changed." I raised an eyebrow, and a friend
remarked "You know, as it always is. Re-interpreted. Rewritten.
Changed." But today, history was made, and that history does not
need any changing!
"The time has come... to set
aside childish things." But not childlike things. Not wonder.
Not hope. Not imagination. Not simplicity. Not virtue. Not a
propensity to action. Not a belief in our own capacity to do, and
make, build, create what we imagine. Not happiness.
President Obama—Amen!
1/20/09 The Grove Wants to Help Turn the Corner
"Our nation is seeing a phenomenal course change this week. As we
all conjure hope, plan for our dreams and imagine our future at the
beginning of a new era, The Grove is offering a special 30% savings
on some of our most popular strategic visioning products to help you
make plans for your own change."
Isn't that a great way to move
forward? Not getting stuck in the morass of today's woes, but
thinking instead about where we want to be, and how to get there.
What are our customers' hopes and dreams? And the hopes of dreams of
everyone in the value network, inside our organization and outside?
How do we put together value, so that despite the economy, we create
the kind of compelling value that gets us where we want to go.
But, times are tough, and since
you probably won't find
the 30% off coupon code at something like CouponCabin or RetailMeNot,
you could email Noel underbar Snow at Grove. (No, we haven't joined
The Grove affiliates program; I like being a free agent.)
1/20/09
New SOA-Erl Books and Community Site
Earlier books by Thomas Erl that have given rise,
in my assessment, to a SOA-ERL architectural style:
And more from Erl:
1/20/09 Pulling Together
Principles References
I'm pulling together references
on principles.
I've made stabs at that before, so those first:
Examples of Principles
from Outside of Software and Enterprise Architecture
-
Definition of
principle on wikipedia
-
principles definition from BusinessDictionary.com:
"Fundamental norms, rules, or
values that represent what is desirable and positive for a person,
group, organization, or community, and help it in determining the
rightfulness or wrongfulness of its actions. Principles are more
basic than policy and objectives, and are meant to govern both."
Principles governing (professional) conduct:
Examples
in Software
Examples in Enterprise
Architecture
Guidance on Creating EA
Principles
Your Help
If there is a paper or set of
example principles that you like, please share it with me, and I'll
share it with the community (with credit to you, if you allow me to
mention your name).
[1/5/09: ARMA
code of ethics
and Kennedy's
Consumer
Bill of Rights.]
1/21/09 Greatness is Earned
Grady
Booch's selection (1/20/09) from Obama's speech reminded me of
his
witty quip (post on 9/8/08) about IBM, Microsoft and Google.
Anyway, Grady's quote included these important words about the
greatness of a nation:
"In reaffirming the greatness
of our nation, we understand that greatness is never a given. It
must be earned." — Barack Obama, 1/20/09
Greatness must be earned. And greatness is a distinction that is
awarded, not self-proclaimed (though dictators may try).
This reminded me of a piece I wrote in response to Michael Phelps,
about the greatness of a person:
"Being great takes work. And
greatness is awarded. We award that distinction so much more
readily, find it so much more compelling, when the honoree is
uncluttered with vanity and self-serving artifice."
moi, 8/13/08
Which is not to say that all great men and women
are humble. Take Steve Jobs, for example (I don't know him personally,
but the public projection is not of a humble man). But humility is a
supreme quality in a leader, for it allows for, even relies on, the role
of others in making headway toward great accomplishment.
"It is by grace and by the efforts
of those before me and beside me that I am where I am and can do what I
do, and for that I am humbled." -- Grady Booch,
blog post on
1/20/09
Greatness interests me greatly, of course, for the mission I've
wrapped my identity around, is to help architects be great.
1/21/09 What it Takes to be Great
Being that my mission is to help architects be
great, I can only strive endlessly to be great by helping you be so.
Your success is imperative to mine. But it is not sufficient because,
well, you bring something to this too (so,
alas,
I don't get to rack up your every success on my scorecard)!
Moreover, to be great, you depend on all those who work with you to make
your system great, and I depend on you.
So, I'm rather far back on the big food chain of greatness. :-) So
far back, that it takes only the biggest of people to notice and say
that I or we (Bredemeyer Consulting) played a role, if only to fuel the
torch of the pursuit of greatness.
Looking for wording around architects being great,
I read over the workshop FAQ on our upcoming
What it takes to be Great: The Role of the Architect Workshop
and this piece, in particular, struck me:
What is the value of this class?
A successful architecture forms the platform for strategic advantage. By
contrast, the lack of architecture bonds the organization inescapably to
its past. Our legacy is a tortuously tangled slew of haphazard systems
born of a time of amazing wizardry but little system discipline. These
legacy systems are expensive and hard to change, but replacing them
threatens the very "life" of the organization. To break the chains of
our corporate legacy and build systems that fit the environment, and
adapt with the environment as it changes, we need superbly talented
architects. Just architecting adaptive systems requires a lot of our
architects, but our architects have, at the same time, to lead the
organization into a new era of system thinking and system discipline and
this requires an even greater set of talents and repertoire of skills.
We understand the multifaceted
nature of the challenge, and this workshop is designed to help
architects see where they have strengths and how to build on them, and
where they have gaps and how to address them.
Literally thousands of very
talented and experienced architects and tech leads have taken our
classes. Even the most experienced architects consistently identify
important insights and lessons that the class has brought to them. We
use some lecture to cover concepts and conceptual models to help
organize and expand knowledge and insight, but our emphasis is on
stories shared by peer architects and the instructor to expose hard-won
lessons, as well as large group, team and individual exercises to learn
techniques and practice skills.
Role of the Architect Workshop FAQ, Bredemeyer Consulting
Goodness, why isn't that class full already?? Wry
grin.
1/22/09 Happy
Almost Anniversary
I'm going to share some of
Charlie's response to my unabashed
solicitation for compliments on the almost-occasion of the 3rd
anniversary of this journal.
"So why do I visit? There are
several reasons:
-
Your writing style is
informative and entertaining at the same time. This is a terrific
quality, and is the primary reason why I prefer the undercover
version. If you are going to eat an ice cream cone, there’s little
point in tossing the ice cream and just eating the cone.
-
You consistently champion the
most important topic in architecture – figuring out what people
really want and need...
-
You do a really nice job of
keeping me posted on what’s going on in the industry...
-
...
-
I know how much you like to see
page hits and want to do my part.
So, keep up the good work!"
I feel the same way about ice cream. In fact, keep
the cone—I'll take my calories with a full helping of cholesterol thank
you.
As for page hits, thanks to each of you for doing
your part! In the general absence of direct feedback, I take your visits
as an implied compliment—especially the increase in the return rate of
visitors. Actually, this last is a troubling phenomenon, because it puts
pressure on me to deliver ... ice cream.
1/22/09 Text, Context and Subtext
I'm preparing for a meeting with some architects,
ostensibly to go over the text of a couple of their documents. But what
I need from them, to make any impact, is the context: objectives and
priorities and a broader perspective that informs the objectives and
priorities. And the subtext. And this is where things get really
interesting, for it is about trying to get the elephant in the room
talked about in a way that doesn't raise resistance and barriers, and
lets us make everything discussable without driving wedges. (Yep,
Randy Pausch left
his mark on my cognitive frameworks in distinctive ways, and that
"elephant in the room" notion is powerful.)
There are those (and not just "IBM") who dismiss
talk, but dialog is essential in understanding the opportunities and
resolving the challenges inherent in architecture. Enterprise, product
family and system architecture by nature cuts across charters, and the
turf battles are often not overt nor even discussable. Everyone is
working for the same company; to suggest an impedance mismatch between
the parts is tantamount to suggesting disloyalty. So the needs,
concerns, passions, values of all the vested parties need to be heard,
understood, integrated into the decision space.
1/22/09 Microsoft Layoffs
Microsoft has caused a stir with 1,400 laid off
today and news that 3,600 more are set to lose their jobs "over the
next 18 months." For those impacted, it's a shock. What came
as a surprise to me, was the amount of anti-Microsoft venom that was
being unleashed in the comments on
mini-Microsoft's blog. In the varied encounters I've had with
Microsoft people, I've been very impressed by how smart and
gracious and multi-dimensional they are. Energetic, interesting,
caring and responsive people. Ten years ago (when I didn't know very
many Microsoft people), I might have succumbed to the caricature of
a smart guy with the arrogance of a top league super-star, but I can
most emphatically say those are not the Microsoft people in
my relationship/experience base! Smart, yes—superbly. Shallow and
arrogant, no. So I feel bad for the uncertainty
the news brings, but worse for some of the actual reaction!
Microsoft has been playing an important role raising the standing of
our profession and
helping to extend our field's knowledge-base and tool-sets. They
deserve applause and I hope it will be heard above the din of the
bad news.
Closer to home: I was wondering, seeing stores and
businesses in Bloomington closing every week, how many people in
Bloomington alone have lost their jobs.
The
storm is upon us. And yet we have clients all
over working on really exciting projects, and I think the bigger news in
the Microsoft announcement may be that those who can are putting a
cautious foot on the spending brake because aggressive cuts will put
more spin in the downward economic spiral.
1/23/09 Delight: In Translation
I know, I beat the "delight" drum ad nauseam for
while back in 2006/7 (12/19/06,
1/24/07 and
1/25/07,
2/1/07,
5/15/07,
11/30/07 and even
3/2/08). At TED,
Yves Behar said:
"Advertising is the price companies
pay for un-original designs."
And advertising is the price we pay for products
that don't sell themselves, don't create advocates in word-of-mouth
customer-to-customer promotion. In
Opening Up the Innovation Engine I made the following point:
"We can't expect marketing
to create brand miracles no matter what products we create, and we can't
expect our sales force to create customer relationships and sell our
products even if they generate bad feelings by delivering a shoddy
customer experience!"
-- mere moi, 6/17/06
There's an important relationship between
strong designs, quality products and marketing, and I'm excited
about a paper I read today. Now, at first blush it is not on point
for software architects: "Winning
Back American Consumers" was first published in Chinese and
directed at marketing and strategists (by UC Berkeley Haas School of
Business professor Lynn Upshaw).
But consider this, as an industry, unless we focus
on quality that delights in software, we will deserve the same tenor of
lecture from Upshaw as China was getting! Our branding as an industry is
tarnished by systems that fail in news-worthy ways, but more insidiously
every day by user experience that frustrates. Does that matter? Well, it
impacts our ability to attract design talent, for one thing. While software
development is seen as a geeky pre-occupation with technology (for its
own sake), rather
than an exciting design domain focused on
user experience that
is meaningful and delights,
we're behind the eight ball on attracting from other talent pools, especially talented
women, into the industry.
So, anyway, I think the paper holds a lesson to be
taken to heart as an architect, as a business, and as an industry. Ok,
some translation is required (from messages directed at China) to
software and architecture, but the essay makes important points about
the relationship between quality/product integrity and brand integrity.
Though
Lynn Upshaw's focus is marketing,
he is quite clear that brand is about design and quality, not just
marketing:
"Integrity for brands is very
similar to personal integrity. It is about standing for something real
and authentic in the eyes of customers and prospects, no matter what
might happen within the marketplace. Such integrity can become truly
disruptive to the competition, especially if it is an industry that may
have had in the past one or more competitors that did not always take
the high road."
Upshaw writes:
"Create Systemic Integrity –
... The stakes are so high in this relationship between China and the
United States that there will always be the temptation to reduce costs
that can threaten product safety, to soften quality controls, and to
produce and sell goods and services in questionable ways.
For China – or any country – to
address this temptation for the indefinite future, there must be an
integrated set of values and actions that are adopted at the
manufacturer/marketer level if superior quality is to become the norm.
It is in this last arena that the problems are the most difficult to
solve, and yet provide multiple benefits for both buyer and seller, once
they have been solved."
If we reframe this in terms of technical/design
debt, we find ourselves slap in the middle of the systemic integrity
point. The temptation to be fast, increasingly under the nom de guerre
of agile, can soften quality controls and
threaten
product usability, reliability, safety and lifecycle cost.
Upshaw recommends:
"Assess quality against the
ideal, not the adequate – Frequently, there is a temptation to do
what is necessary, without considering the normative. Companies with
strong product integrity compare their performance to the ideal, not to
the common denominator."
Well, I've been ordered back to
"my life"... Dana has a bit of a travel hiatus, and is reading
The Hobbit at bedtime.
1/24/09
Integrity and
Engineering Excellence
Now, let me hasten to add, that
I don't harp on about "delight" and "product integrity" only because it
is important from a standpoint of value to the customer:
This "circle of
excellence" notion is exciting, because it brings to the foreground the
fact that for customers, and for development engineers,
excellence is compelling.
moi,
11/30/07
I think it is essential to our
organizational "health," to internal organizational integrity, that we
create soundly engineered products that delight customers. Engineers
want to be on the winning team, to be proud of the products they
engineer—proud of the market success and proud of the product's
integrity. Nothing has impacted me more than working on a project where
quality was slip-slip-slipping under the schedule gun of overly
aggressive weekly integration
targets. The morale level was disturbing, and it wasn't the pressure per
se. People liked the camaraderie of working so hard together to make the
targets, but the undercurrent of concern about quality, about technical
debt, was eating away at that camaraderie like a cancer.
Now, before you think
that I let the lesson of that experience color my attitude towards
agile, let me hasten to say that I think there are two agile tides out
there. One, where "agile"
is the facade behind which projects hide many of the ills that plague
software development; erosion of structural integrity or design debt
being one. Quality issues and technical debt (a front for quality
issues) are bad for software and bad for the "agile brand." True agile
is practiced with faithful adherence to
the principles and values of agile per the Manifesto and subsequent
evolution of the Agile philosophy. The same underlying values,
principles and central tenets have shaped the
Visual Architecting
Process, with the caveat that models need to be viewed as bona
fide vehicles for getting stakeholder participation during early (and
short) iteration cycles, and with the caveat that users/customers are
not the only stakeholders we need to take into account:
Remember, as
architects and software developers we have TWO (classes of) voices to
listen to: the voice of the customer and the
voice of the business. The business cares
about our attention to the voice of the customer, because that is how we
compete in the near-term. But the voice of the business is also about
the long-term viability of our business and the systems and products
that support it.
moi,
3/16/08
Engineering excellence is about creating products
that delight, because the user experience is superb and the product
integrity does nothing to erode that experience. And excellence is a
long term value proposition, for it lowers life cycle cost to the
customer and to the business, and lowers sales and marketing costs in an
increasingly savvy, increasingly skeptical, increasingly connected
customer space.
Engineering excellence is good for engineers, and
it is good for business results. The Hewlett-Packard that Bill and Dave
created, proved this.
Of course, I grant that perfection is hard in
software:
So, it is not
just
that humans aren't "fully debugged." It is the sometimes predictable,
often not, myriad interactions that make it so hard for us to get
systems "perfect." The beliefs and expectations of the user, and the
beliefs and expectations of the software designers and developers, are
complex and not necessarily known or knowable in advance of some
peculiar mix of circumstance. Then you get situations like the F22 crash
described in accident report
S/N
00-4014.
moi,
3/23/07
But the pursuit of excellence is
integral to our pursuit of happiness.
1/25/09: Here's a great story
about
technical (a.k.a. design) debt. Life is full of compromises. But if
we let the compromised system hit the market (ship the prototype), we
create an integrity deficit. And we don't want to be associated
with a phrase that is associated with... ok, moving on...
1/24/09
Trust and Integrity
I grabbed
The Speed Of Trust
as I hurried out to do the ballet lesson "taxi" run. I had balked
at
reading it, though I've come to recognize that some good insights do
come packaged in pop-management books and I'm pretty good at speed
reading through chaff. (And you, no doubt, have become well practiced at
speed reading your way through this journal... hoping to find some
calories and cholesterol in amidst all this fiber. See, this is what I
like so much about my audience—you're full of optimism. You read
this piece, and ever since, you've been full of hope, right?)
I'm a few chapters in and
still feel somewhat reserved, but I'm coming around to feeling it was a
serendipity to grab that book, given that I'd by a fluke stumbled upon
Upshaw's
brand integrity paper yesterday.
Some highlights:
Henry David Thoreau taught
that "for every thousand people hacking at the leaves of evil, there is
one striking at the roots." -- Stephen R. Covey, Foreword to
The Speed Of Trust
Isn't that where
architects should be working—at the roots? And it is, when they can
tackle design issues strategically, rather than being backed into
tackling
crises reactively.
"Low trust creates friction... Low
trust creates hidden agendas, politics, interpersonal conflict,
interdepartmental rivalries, win-lose thinking, defensive and protective
communication... Low trust slows everything--every decision, every
communication, and every relationship."
-- Stephen R. Covey, Foreword to
The Speed Of Trust
and
↓Trust
= ↓
Speed
↑Cost
-- Steven M. R. Covey,
The Speed Of Trust
Ok, I don't like seeing
an "equals" sign in that relationship, but I have scolded myself for
being pedantic. It is a schematic of a relationship that
is important to reveal: Lower trust reduces speed and increases cost.
This could be an emblem for
agilists: more trust→more speed and less cost.
Ah, but Covey also points out that trust is a function of competence and
character. Even the most competent team can give way to the
stories we tell ourselves about expediency and the necessity of now—this
extraordinary moment. And sometimes it is fine, and we work off the
debt, but when we don't, the debt mounts, and we wake up to find the
storm is upon us.
Speaking of storms, Obama's
words capture eloquently the tenor of our time:
"Yet, every so often the oath
is taken amidst gathering clouds and raging storms...
That we are
in the midst of crisis is now well understood.
Our nation is at war, against a far-reaching
network of violence and hatred. Our economy is
badly weakened, a consequence of greed and
irresponsibility on the part of some, but also
our collective failure to make hard choices and
prepare the nation for a new age. Homes have
been lost; jobs shed; businesses shuttered. Our
health care is too costly; our schools fail too
many; and each day brings further evidence that
the ways we use energy strengthen our
adversaries and threaten our planet.
These are
the indicators of crisis, subject to data and
statistics. Less measurable but no less profound
is a sapping of confidence across our land — a
nagging fear that America’s decline is
inevitable, and that the next generation must
lower its sights."
President
Obama,
Inaugural Address, 1/20/09
1/25/09 "Thank you for
telling the story of James Madison"
A heart-warming snippet in
Dana's email today:
"Thank you for sharing the story on
the US constitution and enterprise architecture. I've just arrived, 4
months, in Brussels at the European Commission and today I made the
connection between separation of powers and separation of concerns. A
search on this led me to your story.
A great inspiration!"
-- personal email to Dana, 1/25/09
Last week an architect "alum" was asking me for a
Madison reference, which reminded me that we've stopped including the
What it Takes
to be Great executive report in our Software Architecture Workshop
binder readings section. That's such a pity—we need to go to a separate
readings book like the one we have for the Enterprise Architecture
Workshop. Oh, I know, "no-one reads those things." But, I
practice optimism too. Grin.
Anyway, I want to record Dana telling the story or
reading the Madison piece from that paper for our
Resources for Architects
website. Dana has a great voice for that!
1/25/09 Doctrine and Principles
I'm wrestling my way towards another set of
distinctions, this time in the principles, doctrine, values, space. I
see lots of grey, and I'm trying to find the edges between the concepts,
but they are murky. See for example:
Doctrine
(Latin: doctrina) is a codification of beliefs or
"a body of
teachings" or "instructions",
taught principles or positions, as the body of teachings
in a branch of knowledge or
belief system.
... doctrine
is also used to refer to a principle of law, in the
common law traditions,
established through a history of past decisions, such as
the doctrine of
self-defense, or the principle
of
fair use, or the more narrowly
applicable
first-sale doctrine. In some
organisations, doctrine is simply defined as 'that which
is taught', in other words the basis for institutional
teaching of its personnel about its internal ways of
doing business.
wikipedia, as of 1/25/09
The "principle
of fair use" is defined as:
Fair use is a
doctrine in
United States copyright law that allows
limited use of copyrighted material without requiring permission from
the rights holders, such as use for scholarship or review.
wikipedia, as of
1/25/09
All of this is important to
identity. Who are we, what is our core mission—these are
integral to identity. But more, what values and principles define
us, and what guides our decision making?
1/25/09 Procrastination Dilbert Style
Scanning through Dilbert comics (inspired by
Charlie Alfred; but Charlie sure has a greater density of good Dilberts
than Scott Adams!), I didn't want to lose track of these:
1/26/09 Architect as Consultant
1/26/09 The Importance of Play
Some time ago, I mentioned a company safety policy
I had to sign at a client site that disallowed "rough-housing." Going
in, that felt like a real downer, but fortunately it was not upheld to
the letter, and the R&D community was as playful as one might hope. Now,
I caught and gave Ryan a good "whoopin" this morning, and he got ready
for school laughing gleefully. Covey argues that trust makes things
quicker, but fun, and the goodwill it generates, makes things quicker
too! Indeed, Ryan was ready without the usual crabbing about what a
waste of his life school is; a net time saving and
health benefits to boot. Over and over, I forget that lesson—with
my kids, our dog, my work. Back up a little—the
dog? Yes, she loves a great big rough-housing family laugh-fest just as
much as the kids.
Laughter and fun are important at work too. Now,
I'm not advocating wrestling your team curmudgeon into a helpless
position and "whoopin' him good." Still, it does call to mind: one of
the things the SWI did for our monthly "Development
Day" was bring in a team from a comedy sports club in San Jose, and they
ran a day of fun team training. I'm no
church lady
(hmm, referencing SNL from a by-gone era dates one like rings on a tree,
I'm afraid), but getting into and out of a spaghetti tangle with my
colleagues stretched more than my muscles. Even so, we still use some of
the "exercises" we learned in that event—most
notably, the flying fruit game. It's fun, and great lessons come out in
the debrief about communication (applicable to distributed systems and
system development) and teamwork.
Ok, so I'm not advocating playing "workshop games"
at the top of every meeting either. That guy giving
Happy Go Lucky a dunking for being too happy—he
works in software development, I just know it! But, sometimes, when
things look like they need a pick-me-up, it is just as well to have some
tricks up your sleeve.
Now, you've probably used this, but if you haven't
there's the
Greg the Architect series on youTube. What else? Come on, what fun
and funny tips do you have to share with the rest of us?
With the storm upon us, more and more we're going
to have to play all our leadership cards to keep ourselves, and our
teams, looking on the bright side, and embracing opportunity with
enthusiasm so we create self-fulfilling prophecies that are good for all
of us! Remember, leaders
set the tone!
Over 70,000 people lost their jobs today. It's the
work of Dementors
I tell you. The trouble is, the "retail therapy" that was our usual
solution, and which got us solidly criticized around the globe for our
materialism, is being rethought, and there's a world of hurt in store.
[1/27/09]
"We act as though comfort
and luxury were the chief requirements of life, when all that we need to
make us happy is something to be enthusiastic about." - Einstein
Not so fast, Einstein, not so
fast. Our lifestyle is destroying the planet, but without the
non-essential 90% of stuff in our lives, the wheels of commerce fall
right off. And it's not impossible, but it is a lot harder, to be
enthusiastic in a soup kitchen line. So, to turn this around, we have to
turn the planet around. We need to not just put a band-aid on
our carbon footprint, but fundamentally shift how we make what we make,
use what we use, and get rid of what we no longer need. Then comforts
and selected luxuries we can pursue, giving avenues to enthusiasm to all
who create products and services that leave this planet and its people
better for our presence, not worse.
A great big spending wave on
"going green" would be good for commerce, good for our planet, and good
for our sense of self, and breed enthusiasm a plenty.
([2/5/09: Upon review, I see
that Charles Kingsley is also credited with the "all
that we need to make us happy is something to be enthusiastic about"
quote above, and since he came well before Einstein, I guess it would be
better to quote Kingsley on that. But then I couldn't say "Not so fast
Einstein"!)
1/27/09 Economics... and
Artifacts That Amplify the Value
Yesterday I listened to Grady
Booch
reading his Economics of Architecture column from his IEEE Software
series (a column by this title was published in print in 2007). It is richly insightful and vividly
written. Alas, my focus suffered some for
multi-tasking, and I want to return to it. I did dial in on a perhaps peripheral point
though it stood out colorfully: it is important to create
architecture artifacts
and keep them up-to-date as
the architecture evolves—if we don't, we rely too much on tribal memory
which is too leaky and unreliable to trust the viability of systems that
underpin our business to. [Especially
when, given our now culture, our tribe typically leaves less of a graphic trace
to support oral history than the
Bushman did!]
Ok, I acknowledge, I want that
point to be punched up, because I perceive that when the exhortation to
"travel
light" leads to scant out-of-date or no documentation, our complex
systems teams are poorly served. It is possible to have
structural integrity without up-to-date architecture documentation. But
is it likely, and even if it is the case, for how long will this be so?
And it is possible to have a thriving business without structural
integrity. But for how long will this
be so? Many teams get interested in architecture when the burden of
their inattention is overcoming their ability to respond to the
business, to grow, to embrace new opportunities, to move in new
directions. Then the emphasis is on "recovering" the architecture,
modularizing it, nudging it toward a structure that is more transparent
and evolvable. It must be done, but it is hard-going at that point. It's
risky, expensive, slow; like
fixing the engine while driving at highway speed.
Daniel Stroe mentioned "Festina
lente" (in a personal email) and it is such a powerful concept: Make haste slowly. Be composed
when all around there is the urge to hurry. An architecture that allows
for true agility, meaning responsiveness to the market, takes attention.
Yes, explicit attention to the architecture, to the structures that will
allow scale, that will allow the addition of features, that will allow
innovation in product and process, to delight customers and create
efficiencies. Haste makes waste. Ah, but make haste slowly! Not overly
slowly, but with composure, so we do the right things, just enough, to
ensure that we enable our business to be agile. That, after all, is what
we're really after. Agile development is a good thing, if it makes our
business agile; and not, if it bonds our business to the present, which
drifts so quickly into the past.
Thanks Grady, and thank you
Daniel!
Aside:
Minimalist architecture is a core principle
we articulated and advocate strongly.
Minimalist is about the decision set.
With
teeth has implications for documentation.
1/27/09
Bushman, warriors,
...
I was looking for a
sketch I'd done of Archman showing his son the architecture drawings on
the cave wall of his tribal ancestors... didn't find it. I suppose that
means there's a sketchbook waiting to be scanned in somewhere. But I
found the code warrior... bugs circling,
a saw to hack rather than cut code, Viking... it's the sort of thing that would get me lynched if it
fell into the wrong hands!
That's so not a developer
any of us has ever worked with, right? And it's certainly not an
incarnation from my past. Grin.
Perhaps he'd best go back where
he was—disguised as humor and clinging to hope at the bottom of
Pandora's box!
[1/30/09: I thought ugh, taken
out of context, that image is so potentially offensive I should remove
it. Then I had a still more wicked image -- the Agile code warrior: as
above, with a chainsaw (hack faster). But, of course, I won't go there. There are some
who use the Agile brand to front a "quick-and-dirty" approach, but they
are not following the spirit and the expression of the Agile values. No,
such an image would be like tainting the artist by
pointing to a poor imitation
by an unschooled opportunist.
Oh, please remember, I'm
assuming an audience with an intelligent and wry sense of humor! And one
has to be allowed some fun! Just, shhhhh, don't tell Scott and
don't tell any fake Agilists.
And yes, I am familiar with the
origin of the term "hacker"! I'm also familiar with how it has come to
be used.]
1/27/09 The Most Important Thing
I came away from Obama's
Inaugural Address going "great content," yet wondering what punch-line
action I was supposed to have been inspired to take. I know I was
distracted, and rereading the speech has been very rewarding. It is my habit, on holding a
mirror up, to take a peek myself. And so I thought, ok, the key
point I wanted people to get when
I
expanded on Grady's "truth to power" piece was "always be cognizant
that it is a human being receiving your feedback." But I never
made that one point. I danced around it, to be sure. But I didn't say it
just like that, so it was clear that was my big point. When we give
feedback, it is because we want to make a difference. So give the
feedback in a way that makes a difference most effectively—in a way
that takes into account the humanity of the person (or group of persons)
receiving the feedback. And, in a way that takes our humanity
into account.
Yes, if I were to boil it all down to one thing, it would
be "remember the human being." A person in power is still a human being,
with all that means. Hopes and aspirations about to be dashed by your
feedback? Defenses about to be raised by your feedback? The human being.
We introverts don't want to deal with all that icky soft stuff that
takes time away from our "real" work. It would all be so much more
efficient if we could just get by with everyone assuming
positive intent,
and interpreting our feedback from that frame of reference so we didn't
have to be careful about how we gave it. But here's the rub: We may see
that they're up a proverbial creek without a paddle, but how do we get
them to take a paddle from us in time to avert disaster? And then
there's our humanity: How much of their perspective do we understand?
And their context? Their pressures? Their assumptions? Their analysis?
So, I found myself realizing
that I hadn't said what I set out to say with exactly the words that most clearly
and memorably expressed
my intent. I suppose that's Composition 101. Too
bad I never took Composition 101!
Not that we want to toss
the ice cream, of course. There's a place for content. And delight--a
happy embracing of life; ice cream, if you like.
1/28/09 Embedded Software
Architect Position
"I am looking for a Software
Architect in North Carolina. The position requires embedded experience
as well as Linux and C++. If anyone is interested they can contact me."
Amy Carmichael,
www.itiselect.com,
acarmichael[at]itselect
For more information, see the
Architect Jobs page on the
Bredemeyer site.
1/28/09 Love Those Carrots!
"I have been using
the Bredemeyer website for a while. Yesterday afternoon I noticed
one of the articles I had not read yet (“Getting Past ‘But’: Finding
Opportunity and Making it Happen”). Not for my surprise I found it
superb. The article comes at a very interesting time when I have
been questioning some of the aspects you describe so well in your
article regarding ‘innovation trap’ and creativity."
Simone Marsland,
email 1/27/09
Thanks Simone!
That cast a bubble of
warmth around an
otherwise cold day in Indiana. When you pour passion into
something, doing it should be reward enough, right? Getting to
do creative work is certainly a privilege I recognize and value.
Yes, it is rewarding to work hard on something, to have generous
and insightful thinking partners work hard on helping you make
it better (thanks Charlie and Kristen), and to feel like you did
a pretty decent job. But you're still not sure, because
value is in the eye of the beholder. So it is very rewarding to
have architects write, from time to time, and say that what we
did was helpful—superb even! Wahoo!
Don't worry, a
carrot or two on a stand-out week won't go to my head. And nor
will any carrots you are hereby inspired to pass on to your
colleagues.
"Goodwill is the silver
bullet."
-- Dana Bredemeyer
Goodwill? I
mentioned goodwill
here, and
here, and
here.
1/29/09
FollowSite
Since this journal
is updated so frequently, an RSS feed on it would be very noisy!
Likewise, you certainly don't need to track changes to it on
something like
followsite—but
I mention
followsite because you might find it worthwhile to track the
Bredemeyer Resources for
Software Architects site. As for
delicious,
stumbleupon, reddit and
the like, I realize you don't need to keep track of where to
find me, but it would be kind to me if you'd bookmark my
journal site, and our Bredemeyer
Resources for Software
Architects site.
1/29/09
Principles versus Postulates
Ok, add postulates
to principles, doctrine and values in the identity terminology
soup! Mark Lane (indirectly) brought Easton Rhodd's "Enterprise
Architecture Postulates, Principles and Objectives: Finding
the Discipline" working paper to my attention.
"In
traditional
logic,
an axiom or postulate is a
proposition that is not proved or demonstrated
but considered to be either
self-evident,
or subject to necessary
decision.
Therefore, its truth is taken for granted, and
serves as a starting point for deducing and
inferring other (theory dependent) truths."
wikipedia
1/29/09 The Code
is the Truth
Grady Booch has
received some enthusiastic head-nods from developers for his "the
code is the truth"
phrase. It's catchy and there's truth in it... and still I feel uncomfortable with
that being the phrase that gets ping-ponged around. For the truth in
the code interacts with the environment, and with other code,
and you have to know more than the code that is in front
of you, to really know "the truth."
If we look at any code snippet, can we tell if it will be
fast? useful in only one context or across many contexts?
robust? The truth, if you want it, is that many system
properties are emergent not just from system evolution, but
from interactions within the code and with the environment. A
rnon
Rotem-Gal-Oz's
1/14/09 blog post illustrates very nicely the
context-sensitivity of the "truth."So we start to teeter on the point that
the code is the truth,
and shade into the code is
not the whole truth (Grady
Booch, cnet). And it is
very hard (to arguably impossible for large systems) to get our
arms wrapped around all the truth held in the code when we have
just the code to work from. Structural analysis tools help see
some of the hidden truth—hidden because the code-as-truth can be
a rather long-winded telling of the truth we're interested in.
Performance analysis tools help, because they reveal what the
code by itself does not—what comes of interactions with the
environment.
And keeping an up-to-date set
of architecture views and documented decisions along with their
rationale, justification, explanation, assumptions, etc., helps.
Of course, there's the rub. Up-to-date.
That's where this "code is the truth" thing originated and
gained such enthusiastic energy! We let the architecture
(documentation) get out-of date, so that it does not map to the
truth in the code, and we cannot trust it.
This is why I've talked about the bigger
truth that is in our organization (roles and responsibilities)
and process. Unless we make it a responsibility to maintain the
architecture-as-truth, it is very hard for us to leverage the
truth that is in the code, to wield it for good.
If the code is the truth but not the whole truth, the
architecture (documentation)
needs to reflect the whole truth in strategic terms. Strategic
terms. Terms that take the business and the environment into
account.
Then the question is, should the architecture (documentation)
follow the code, abstracting, rationalizing and contextualizing the truth? Or should the
architecture create the truth that the code expands upon? Or
some of each—intentional and emergent?
Yeah, yeah, you know what I think. But I'm
still trying to figure it out! Grin.
1/30/09 Caveat Lector
Which serves to remind me—from time to time, I use Grady Booch's writing as a springboard to expand or (re-)organize my
thinking. Of course, if we had access to all of Grady's
thinking, mine would be (still more) redundant. So, by
Yang I only mean I'm filling out my cognitive space, and
imply nothing about anyone else's, and particularly not Grady's!
1/30/09
Down to the Wire!
Ok, you've marked
your calendar and you're going to send your kind words of
celebration and support on February 3, right? Right? What are we
celebrating? This journal turns 3 on Feb 3. Oh well, as I said
last year:
maybe next year... Grin.
Thank you Charlie
for not letting the event go unmarked; it is amazing to me that
someone I admire so much reads my journal from time to
time. And thank goodness—Charlie's input to our
Getting Past "But" report, and to my thinking about
complexity,
value modeling and architecture more generally, has been
invaluable! Daniel,
you got a head-start too, and your
Thanksgiving
note stands out from all the kind words I've received in my
career; thank you. So often, with just a few words, you have
shifted my worldview—and that is in masterful contrast to my
so-many words! And
Clayton, thanks for the "brain architecture" tribute to my
"architecture on the brain."
And thank you (again) to Grady Booch, whose blog inspired this
journal. I had been following Grady's blog for quite some time
before the coin dropped—he'd created a permutation on the blog
theme that I liked: journaling on his site, and piping his
entries to his IBM DeveloperWorks blog. Well, I didn't want to
pipe journal entries to a blog, because I like (no, definitely
need) to be able to edit my entries, and the blogosphere
ethic disallows that (for good reason; you don't want to change
the basis for discussion once a discussion is under way)!
So my planned permutation was to mine this journal for
interesting bits to craft into
blog entries,
and I have, on occasion, followed that plan. Anyway, Grady's
modus operandi—-the form it took and the vivid and often
personal quality of his online journaling—inspired me.
The rest of you who remain nameless, thank you for making me
both more shy and not shy enough!
Anyway, thank you for letting me
practice being me, and giving me the grace of your company.
1/30/09 Upcoming Workshops
If you know anyone who would be interested
in these workshops, please do let them know so they can get a
seat in the case of the Software Architecture Workshop, and take
advantage of the discount in the case of the Architectural
Leadership Workshop.
As many
of you are know, our workshops
attract a very fine set of architects, which makes for a
great experience at the time, but also creates a strong
network of talented peers. Our Architectural Leadership
class runs internally almost as often as our other
workshops, but just takes a bit more time to get traction
when it is an open enrollment class. So, it'd be great to
have your help getting the word out about it!
1/31/09 Ah, Now I Get It!
Ryan is
into combat flight simulator. This morning, for mars, he
dropped all his bombs and flew under them to see if he could
take himself out. He did too! Walla: I now understand what
all these layoffs are about! Let's see, cut our labor force
so the unemployed aren't spending and the news freaks out
everyone who still has a job so they stop spending. Boom!
Shot right out of the sky by our own bomb!
I
wrote more, but I got so sick of myself I ripped the piece!
So, make what you will of the metaphor. I got a kick out of
it.
[2/1/09: Fortunately Charlie stepped in:
"You
did a nice job of looking at the system dynamics from
the business’ perspective. The business is motivated to
lay off people to cut expenses, but fails to see the
ripple effect coming back as a reduction in sales.
I
told my wife something similar, a few months ago – back
when there was a lot of discussion of the merits of tax
cuts, tax credits, or stimulus packages. I asked her,
“How
many people are going to use the stimulus check or tax
cut to pay down debt, or sock it in the bank because
they are a afraid of what the future might hold?”
Such
stimuli fail to achieve their goal of giving the economy
a jump start by stimulating spending, because too many
people have strong incentives to do anything but spend
the money.
This
is “the border” where microeconomics meets
macroeconomics. Nobel-winning economist Paul Samuelson
said,
“microeconomics tells us that any given farmer improves
their profit by growing as many crops as possible, but
clearly this statement cannot be made for all farmers.”
In microeconomics, the key
assumption is that the individual (consumer or business)
has no effect on the whole. In macroeconomics, the sum
total of the behaviors of all individuals
are
the whole.
So,
what this all goes back to is the admonition to “think
globally, and act locally.” If a thought or motivation
occurs to you, the same thought or motivation may occur
to thousands or millions of others who think like you.
This awareness of systems dynamics needs to enter our
collective consciousness, stay there, and motivate
behavior.
Architects are trained to think like this, when they
consider things like tradeoffs, risks, contexts, and
system evolution. In fairness, some stakeholders and
developers also think this way, but many do not.
Conceptual distance makes people think locally and act
locally (but with global side effects). It is the
responsibility of the architect to help local thinkers
understand the bigger picture, and make decisions in a
way that helps increase aggregate value."
-- Charlie Alfred,
personal email, 2/1/09
Ah yes, would that every CEO would put that "cautious
foot on the spending brake because aggressive cuts will
put more spin in the downward economic spiral."
"These businesses will
have realized that the risk of doing the same old thing is
greater than the risk of trying something new. I think the
these are the ones that will lead us out of this recession.
It certainly won't be Chicken Little."
"recession
survival tactics" blog post, Tom Fishburne, 1/31/09
1/8/09
An architect once told me "I think best in code; I just can't think
in diagrams." We could gasp "and he's an architect??" but I
totally
We
can experiment in models, to help us focus where we need to
experiment in code.