07/01/10 Your Co-ordinates
This journal contains notes I
take as I explore what it takes to be a great software, systems and
enterprise architect. This may be some aspect of the architecting
process (like iteration, refactoring and documenting decisions), or
it may be a characteristic or skill that is useful to develop (like
humor or influence and persuasion). This is a journal of the more traditional
sort--a place to keep track of pieces of my exploration, and a place
to write as part of my meaning-making process. Anyway,
month's entries are linked in the sidebar on the right.
this month are listed below the links to the archive, and the
07/02/10 The Art of Change: Fractal and Emergent
The Art of Change: Fractal and Emergent is at last
complete, and The Art of Change: To Lead is To See, To Frame, To
Draw is back on my "discretionary time" priority stack.
Hopefully you'll read Part One: Fractal and Emergent (the what and
the why) and be eager to read Part Two: To Lead is To See, To Frame,
To Draw (the how). Naturally that will also go through
review/improvement cycles, so if you are interested in getting to
read the report before everyone else, offer to review it! Grin.
Now, I should say that emergent is what we get anyway and easily.
Right? We're always responding to, adapting, adjusting on the fly,
inventing in the small, seeing, and shaping, within our field of
influence. Business strategy and its tandem architecture creates
coherence of purpose and concert among the many socio-technical
systems, the many smaller pools of action and influence, within an
organization, so that bigger, more ambitious, impactful things get
done. While embracing emergence or extemporaneous dynamic
responsiveness, we also note that achieving an ambitious vision takes intentional
focus on making what is impossible or very unlikely through sheer
accident, and aligning inspired creative, inventive thought and
action so that many contributions of mind, will and hands build that
Fractal strategy and tandem architecture are not new--we have
just borrowed Bezos' image and put words to what is done, varyingly,
in organizations. The important thing about creating this image
though, is that it gives us a way to have the conversation about the
relationship between strategy and architecture. Why? Because this is
done varyingly in organizations--even within one organization, there
is inconsistent understanding of the role of strategy, let alone
In some cases, strategy is viewed as a "bad word"--there is "no
strategy," and that is treated as a point of cultural pride. A point
of cultural pride. Hmmmm, that sounds like identity, which is a key
part of strategy. So strategy in the organization is fractal,
with an independent "cowboy" (shoot first and aim after) culture set
as the unifier at the corporate level, and other elements of
strategy pushed out to the business elements. But as soon as that
company wants to achieve something more coherent across its
businesses, it finds itself needing to work strategically and
architecturally to create a shared intent and the relationship
platform for enabling that coherence. So, whether "dynamic, organic,
fractal strategy" enters their parlance, allowing them to explicitly
talk about intentional and emergent strategy or not, they have to
get more intentional if they want to do those bigger things that
require concert to make them more the way they would like them to be
(Herbert Simon's wonderful way of defining and motivating design).
Dynamic? Allowing for learning and responsiveness. Organic?
Embracing empowerment and emergence. Fractal? Set at different loci
in the organization. Strategy: read the paper. Wink. And tandem
architecture? Oh right, now we're getting into a number of papers,
websites, ... Smile. But the paper is a place to start. I do hope
you'll want to read it. And recommend it. We should have the URL
after the long weekend. Grin. [7/14: Here it is:
A couple of reviewers mentioned that the report is "advanced
reading" for an entry-level architect. I hope not. I hope that it
persuades managers and architects that there is an important bridge
between architecture and strategy, and that bridge doesn't have its
foundation entirely in the business side, nor entirely in the
technical side--but rather in a partnership where strategy and
architecture work together collaboratively. That is, they inform and
are informed by each other, enhance and are enhanced by, lead and
are led by each other. And I hope that the paper unfolds the salient
topics in an accessible manner--accessible to both managers and to
architects, to motivate and enable that bridge-building. Enable,
because the most important thing to ability is the conception of the
thing being worth doing! ("Most important" is strongly put, and
provokes a question of accuracy, but my sense is that it is right...
I'll have to think more about it though. It seems right though also
not complete, like necessary but not sufficient... and while not
sufficient, it creates the drive to assemble all the sufficiencies...
Look, that is what it is like to be in my head. If you don't like
it, you don't have to read this. But I have to live in this head!
You could have some compassion! Grin.)
I drew a cartoonish sketch of the strategist and
tandem, but I really wanted to add another where the tandem with the
architect out front steering wins the race. I didn't*,
because races are dynamic and unpredictable, and sometimes
technology-led innovation wins, and sometimes customer-led
innovation wins, etc. And this can happen in the same industries so
there is no magic recipe. Magic. Incredible connections. But no
formulaic recipe. No algorithm. Not even a pattern we can
mechanically stamp out.
By the way, on our Hobie tandem kayak, steering is done by the person in the
back. Perhaps that is a better image. :-) But kayaking tandem sure reminds
me of the importance of persuasion and influence--if I sit in the front with the
camera to catch the bald eagles and herons--and deer swimming across the lake
(who knew deer did that? not I!) then I have to communicate and persuade the
person at the rudder to go where I want to go!
* Ok, ok, I didn't because I am time-constrained--meaning
lazy... uh, I mean busy... :-)
ps. don't you like the synchrony between the strategist and Archman in the
sketch? I'm so often amazed by what the "hand" knows that the conscious mind
wasn't explicitly working on... I wish I could draw better, but it's still
interesting to see what comes out when I (try to) sketch. And that's part of
what is so important about drawing and visual modeling, isn't it? The something
new that we see in the relationships that visualization makes apparent. This
video of Milton Glaser talking about thinking
while drawing (by way of
David Sibbet's blog) is salient. Dana says he has read/we have the book
Glaser refers to--The Hand. Dana just hadn't connected it with the
visualization dive I've been on, but says it is quite interesting.
pps. I love the Wordle of the paper. It was Ryan's suggestion--actually, he
suggested that instead of writing the Executive Summary, I just create a Wordle
image. I liked that idea--a lot! Alas, I wasn't able to sell it. Grin. Anyway, I
love that it looks like an arrow, and strategy aligns and points in a common
direction, but it's not a perfect arrow, and that comes from emergence. But
because it is not perfect, it also looks like a tree--trees are organic life
images, so that is neat. And the trunk of the tree, on which all else rests, is
and that is a useful reminder for us technologists. And
is the load-bearing central point of the tree and the arrow. Wordles are great,
because our meaning-loving minds can find some, even when it's randomly
generated! Grin. Still, if you look at the words that pop out as the top
words in the paper, doesn't that just make you want to read it? No? Oh dear.
Really? You're not intrigued by "strategy, value, capabilities, architecture,
delight"? Or "integrity, architects, design"? Or "system, change, architecture"?
7/2/10 Prescience and Intentionality
7/2/10 On Failure
System faults and failures--some examples that made the news
Google is killing wave, Wall Street Journal, August 4, 2010 [added
World's Worst Oil Spills infographic, June 8, 2010 and
Jumping the Walrus:
When Risk Management Goes Bad, Robert Charette, July 2, 2010 and
BP's Safety Record, Jun 9, 2010
Apple Speaks on the Matter of the "Death Grip," July 2, 2010 and
The New iPhone's Other Performance Problem, July 2, 2010 and
Says iPhone 4 Reception Mystery Is Solved! AT&T's Signal Was Never
Really There! by Kit Eaton, FastCompany, Jul 2, 2010 and
Free Bumpers, July 16, 2010
Microsoft Pulls Plug on Kin Phones, June 30, 2010
Virgin Blue's Brand New Airline Reservation & Ticketing System Crashes,
June 18, 2010
The Size Of Toyota’s Problem Moves Toward $10 Billion, February 17,
'scary' Prius acceleration problem, February 1, 2010,
Haven't found that software glitch, Toyota? Keep trying, March 2010
Toyota probe: Drivers may have botched the braking, August 11, 2010
TurboTax Software Slows Just as the Big Deadline Nears, April 23, 2010
Intuit Finally Recovers From Maintenance Error Caused By Power Outage,
June 17, 2010
Twitter architect gets hit by the
Bug or architectural flaw? smoothspan blog, April 23, 2008,
Some thoughts on Twitter's availability problems, Dare Obasanjo, May 22,
System health monitoring misfires at
Fixing the root cause of Amazon's S3 outage, smoothspan blog, July 27,
LAX IT failure: Leaps of Faith Don't Work and
NIC Card Soup Gives LAX A Tummy-Ache, Aug 17, 2007
Software horror stories
Classic examples of system failures
On system failure
Medical Devices: D.R. Wallace, D.R. Kuhn, Failure
Modes in Medical Device Software: an Analysis of 15 Years of Recall Data,
International Journal of Reliability, Quality, and Safety Engineering, Vol.
8, No. 4, 2001.
Robert Wears, and Richard Cook,
Automation, Interaction, Complexity and Failure
database: D.R. Kuhn, D.R. Wallace, A.J. Gallo, Jr., Software
Fault Interactions and Implications for Software Testing,
IEEE Trans. on Software Engineering, vol. 30, no. 6, June, 2004.
On project failure
Learning from failure
From my journal
What to do
2010 CWE/SANS Top
25 Most Dangerous Software Errors --
Assessing the Odds of Catastrophe; see also
wikipedia; see also
The Rugged Software Manifesto.
'Rugged Manifesto' promotes secure coding NetworkWorld, 2/28/10, and
Rugged Software Manifesto, Vikas Hazrati, InfoQ, June 22, 2010
Architecture Reviews, Grady Booch, ♫IEEE
Software on architecture #25, July 2010
Defense in Depth post on TheOldNewThing
architecture assessment references
You never learn by doing something right.
’cause you already know how to do it. You only learn from making mistakes and
correcting them” -- Russel Ackoff
"The nicest thing about not
planning is that failure comes as a complete surprise and is not preceded by a
period of worry and depression." - Sir John Harvey-Jones
"Not only are a system’s desired
operating modes influenced by its architecture, but so are some of its failure
modes. Thus an architecture that permits only one path between elements may fail
if a leg of any path breaks. All of a tree below a broken node is isolated from
the rest of the tree."
-- Edward Crawley, Olivier de Weck, Steven
Eppinger, Christopher Magee, Joel Moses, Warren Seering, Joel Schindall, David
Wallace and Daniel Whitney, "The
Influence of Architecture in Engineering Systems,"
MIT esd, March 2004
"Success breeds complacency. Complacency breeds failure.
Only the paranoid survive." -- Andrew Grove
“If automobiles had followed the same development cycle as
the computer, a Rolls-Royce would today cost $100, get a million miles per
gallon, and explode once a year, killing everyone inside” -- Robert Cringely
7/5/10: Ok, so this is spooky--on Friday July 2, I returned to the
failure/risk topic of June
29--And Failure. I didn't think to look in on xkcd until tonight, but did
you see Friday's xkcd? What we are paying
attention to shapes what we perceive and pay attention to, and all kinds of
fallacies in human reasoning are brought up with this one! Like, how often our
deep dive is into whatever is top of mind... tunneling deep is something we
geeks like to do; it makes us feel "safe" to get our analytical (left brain)
juices flowing... it is where education tends to focus, and it is what enables
us to push the frontiers of science and the cusp of what our systems can do. We
want to get to our comfort zone, beyond all the fuzzy uncertainty brought about
largely because there are areas that are not our purview or decision space, so
we tunnel as quickly as we can past the "breadth" space that overlaps with other
stakeholders who, frankly, slow things down and complicate them with messy
it is why one of our biggest areas of proneness to failure is "failure of the
imagination'... failures in direction, and failures in anticipating and
Spooky? Did you get it? The brain wants to makes sense of things. Our drive
to assign cause to effect, to provide an explanation, etc. is useful, but highly
flawed. Here are some notes from my reading of The Thinker's Toolkit that I used
in my SATURN tutorial:
- We instinctively see the world in terms of patterns: Situations,
Relationships, Sequence of events, Categories
- We look for cause and effect relationships: “Humans are pattern seeking
animals. We must find cause and meaning in all events… everything must fit,
must have a purpose and, in the strongest version, must be for the best.”
–Stephen Jay Gould
This need can be satisfied by chance, coincidence, illusion, etc. (i.e., even
when there is no relationship). It is the false perception of cause and
effect that enables magicians to trick us!
7/2/10 Where Technology is Going
7/2/10 Did You get It?
Ok, so I put a placeholder for a post on
Prescience and Intentionality in
this journal earlier today. Looking at it now, it is too funny to change! I
suppose you'd have to be prescient to get my intent! Grin.
7/3/10 Failures of Imagination, or just Optimism
When I first read "most cases of failure... have been in two categories:
imagination and process" (Grady Booch) what I thought most about was
failures in direction--doing the wrong thing because we simply didn't project
ourselves in various ways--into the future when the system is in place, but
other trends and forces have played out too; into use contexts, to
empathetically grok what users care most about, or to assess *ilities, etc.,
etc. I'm not saying all of this should be done in our imagination--but if
the system doesn't exist, it has to be imagined! So we imagine, and prototype,
and build out iteratively, to get a more and more clear sense of where value and
But of course we also have to imagine what could go wrong. And creating a
system, especially an ambitious system, is such an exercise in optimism that we
perhaps are disinclined to think through all the ways in which it might fail. I hadn't thought of this facet of the failure problem before. Blindness to
risk and consequence yes. But optimism, no.
When it comes to the 4th of July, my imagination goes into overdrive, to
compensate for what my pyro-loving family are way, way too optimistic about! It
stresses me out major, but I can still enjoy how pretty it is. All the while
thinking about how things are going to change, as we become more conscious of
climate change and the impact of blowing up a bunch of fireworks that got
transported all the way from China! Every year I say "never again." Then Mythbuster-fan, pyro-loving master Ryan delights his way back into "just a few"
which I won't shop for, so without me there to wet-blanket the affair... becomes
7/3/10 Emergence and Failures of Discipline
The image is a little piece of our home, and it is for me what emergence--with
the lightest touch of intentionality--is
all about. The table is from South Africa, the wooden bowl and fruit is a Dennis Hales piece (UK), the ceramic
and brass lamp is by Stuart Gray (MI), and
the glass bowl is from a gallery in Half Moon Bay, CA. When we bought the pieces
(over the years), each was chosen on its own independent merit, not thinking
about where it would find a home. What unifies, is a coherent aesthetic. Each
such space has its own quality, each quite different. And with the wash of time,
each amasses its odd appendages. Now, that particular table also has a fish
picture by Ryan. It is lovely, and I want to frame it--have wanted to for a few
years. And while it awaits that destiny, it shares that table, along with a fimo
turtle I made (my third try at a fimo creature, so I was quite surprised by it).
And a glass ball my sister gave Sara when she was little, because it is magical
and it's something no-one would ever think to give a little girl--except my sister,
who has her own kind of magic. And so it goes. All of these pieces cohere
sweetly together, yet there is a sense that it is just too much.
Adding complexity. Innocuous at first. Then at some point, it's just too much,
but what goes? Not the turtle! Grin. Some wonderful art, some family legacy, and
it is very "us" and not nearly so pristinely perfect as it was before the
"droppings" of family sentimentality added too much muchness to it.
The stained glass effect on the turtle picks up the pattern of the glass
bowl, its blues and those of Ryan's fish complement the silvers of the Hales
fruit and bowl. But they're schlocky companions to the fine pieces of art we've
picked up here and there on our travels over the spread of years.
So we get to failures of discipline. And the line that is hard to draw.
Especially when sentiment and feeling are involved.
Of course, we never fall foul of this in software development, do we?
7/4/10 Happy Fourth of July!
Happy Independence Day if you live in the USA. And happy 4th of July
7/4/10 Risks and Consequences ... and Checklists
The architect, as the "ultimate design authority" responsible for design
integrity, has to think about the ways the system could fail, and because that
would be a disabling space to get mired in, decide (and bring to the business
partners for attention and resources) which to prevent, which to mitigate, which
to transfer, which to investigate further or to optimistically ignore, etc. And
then we get into the unknown unknowns. But we also get into practices for
sussing out the imaginable unknowns. And then there's the usual suspects. Like
Checklists are good. I'm all for them. They raise our platform of practice,
and advance what we can take on. But judgment is essential, and judgment takes
time. Yes, time and experience to develop, but I mean time on the schedule!
Every single decision we make explicitly takes time, so we make a huge number of
them implicitly. What we ignore is an implicit set of decisions. We have to do
that to cope. Time and other resources are limited. Competition creates an
inexorable onward march.
"It’s all a question of cost versus risk."
-- Keith Armstrong,
Toyota "Sticking Pedals" Recall a Smokescreen, Feb 28, 2010
So, checklists. Patterns and practices. Take availability. When we checklist
the various ways things can and have failed, that directs our attention.
scale demands on estimates given past filings and estimates of switching to
electronic filing, and still seriously underestimated capacity for this year's
tax filing deadline. There is a lot of room for forecasting, instrumentation
and analytics when it comes to monitoring and foreseeing, so we can respond to
known risks. But there are still surprises. And for risks of serious
consequence, there's the response and containment and recovery plans. The plans
for containment given knock-on effects. Imagining the outward ripple of problems
interacting with problems, until a failure of consequence occurs. What could
Intuit have done? What should they have done? I can imagine a few things. Yes!
Imagine! Project. "Be" in that situation beforehand, and think it through.
Again, judgment is called for. And that is my concern about checklists and
architecture document templates and the like. They're good, useful. And we
cannot let them do the driving for us. There are too many interdependencies,
context dependencies, matters of blink intuition and areas where we needs must
invest in serious analytical pursuit to assess and ameliorate or plan to contain
and recover from. Or not. So we can't give good sense over to a checklist, and
hold ours in abeyance, thinking that the job is done for us. We have to be ever
watchful for the difference that makes a difference. It is human to file late.
And it is human to defer thinking about what happens when everyone defers filing
until the last minute. Then it is human to point fingers of blame--away from
ourselves. And so on. Well, we're designing for humans! We need to take that
That caveat indicated, checklists rock. Please give me pointers to
checklists you have found useful, and I'll list/categorize and share them. Btw,
I find that the qualities requirements space has much that applies nicely--for
example, availability requirements speak to characterizing demand patterns and
forecasting, and not meeting
those is a risk of failure, so it is the flip side of the requirements coin. Of
course, our checklists are even more helpful when they point to strategies and
even mechanisms (and design patterns that document proven approaches to
designing those mechanisms) we can design into our systems to address the
challenge (and associated risk that we fail to do so). In the security area, 2010 CWE/SANS Top
25 Most Dangerous Software Errors has both the errors that can lead to
software vulnerabilities/failures/flaws/holes/breeches/whatever and the "monster
mitigations" to eliminate or reduce the severity of the vulnerability.
Here's a couple of links I've pointed to in the past;
Some of the success for Peace Shield II was attributed as follows:
”We had a program manager with enough vision to say, ’What
things can we do to abate our risks?’ and then immediately got out the checkbook
to fund the abatement plans.”
-- Jeffrey D. Vermeer as quoted by Robert Charette
Understanding Failure by Examining Success, Nov 2008
On the importance of checklists:
go to brush leaves out
of her hair, fell off the swing. She got up, dusted
herself off and said: 'Note to self: don't brush off leaves while on swing." I
thought "How can a child smart enough to say that, be stupid enough to just do
Not imagining our way/using prefrontal cortex extrapolation to avert the
mistake in the first place is bad enough; not learning from mistakes we
already made is worse. We want checklists and other accumulated wisdom in our
field and our practice to guide us away from repeating mistooks.
The safety argument fallacy taxonomy in this paper is interesting:
Framing analysis of software failures with safety cases (.pdf), by William
Greenwell and John Knight.
I also write at:
for Software Architects
Architecture Action Guide
Trace In the Sand Blog
Links to tools and other resources
Trace in the Sand
- Journal Map
- The Art of Change
- On Failure
- Where Technology is Going
- Failures of Imagination
- Failures of Discipline
- Risks, Consequences, Checklists
- Unintended Effects
- Business Model Canvas
- That Picture IT
- Iterative Development
- Visualizing--Scary, Good, Trees
- Thing so Fragile
- Architecture Decisions
- VAP =d= Agile Architecting
- Visualization and
- Design Rulez
- Opportunity in Undelight
- Directions for Art of Change
- Late is Better than Dead
- Software Architecture
- What's Worse?
- Leadership Moment
- On the Education of the Architect
- Art of Change Free Download
- Believe in Others
- Apple Embarrassed
- Framing Forces and Trends
- Re-Imagine This
- Visual - Misc.
- Innovation -- Misc.
- I Want One!
- Exposing the Invisible
- MacPaint Source
- Code Metrics and Architecture
- Details that Matter
- Weaving Ruth
- Upcoming Workshops
- Coupling and Cohesion, Modularity and More
- Design Thinking
- Interesting Numbers
- Hard to Catch
- Adding "With" to the 6
- Window on History
- Innovation and Creativity
- For Kindred Seekers
- Architecture Principles
- Software Visualization
- Good Design and Code Value
Leo de Sousa
Jack van Hoof
Agile and Lean
CTOs and CIOs
CEOs (Web 2.0)
Tim Brown (IDEO)
The Tech Chronicles
Social Networking/Web 2.0+ Watch
- Dan Roam
David Sibbet (The Grove)
Strategy, BI and Competitive Intelligence
- Malcom Ryder
Um... and these
Sylvia Earle, TED
- CNN Money
Business of Green
- Matter Network
7/4/10 Risks and Consequences ... and Unintended Effects
When I started the post above, I intended to write about unintended effects,
knock-on effects, the myriad interactions, some foreseeable, many not, that make
systems come undone. But when I grabbed hold of the tail of the idea as it flew
by, and started to pull at it, it morphed into a different beastie... or post.
Humans achieve the amazing! And it is amazing that more doesn't go wrong!
But for Toyota, troubles kept coming in:
Back in 2006, there were various promises from Toyota, including this:
"Moreover, the company has said that it will be more open in its disclosure of
quality problems to ensure that the results of its actions are transparent to
the company as well as the public at large."
The Role of Scared Values in Managing Risk, The Cutter
Edge, September 2006
Of course, there's always another perspective:
Risk, as with truth, is often hard to ferret out. Still, Toyota apparently
thinks there are real issues:
And let's face it, there's a lot of ☼shift
going on in cars these days, and much of it is going to electronics and
software, leading to complex interactions:
These complex interactions
include interactions with humans. And interactions with stuff humans make.
Uh oh. Well, there's a bunch of really interesting
complex systems research going on at
MIT in the Aero/Astro SERL Program.
Just how many parts?
"The most elaborate mechanical watches are called très
compliqué. They are, as their French name implies, complicated. A Star
Caliber Patek Phillipe has 103 pieces. A Boeing 747-400 has,
excluding fasteners, 3x106 parts. In complicated systems parts have
to work in unison to accomplish a function."
Complex Systems, Nothwestern NICO
grand horological complication! Mechanical
Unintended effects. Unintended directions. Interactions. Some predictable,
7/5/10 Business Model Canvas
7/5/10 Other Interesting Links
ever closer to what I want!
infographic on iPad's competitors is interesting. But isn't it missing
something... When I think about it, I realize a key ecosystem shaper is
iTunes--we got locked in to iTunes with the iPod, and now any (sub)platform (iTouch
to add apps/games and movies, iPhone to add phone, iPad to add e-Reader, etc.)
in the family has a distinct edge over the competition because our all-important
listening lives migrate with us to that platform. Lock-in is a big deal, and
Amazon was smart to make Kindle reading possible on other devices, not just the
Kindle. It is interesting to see that Barnes and Noble's nook eReader also has a
free download version for
If we are going to move our reading off dead trees, any forward-looking
bookstore wants us to get locked-in to their e-books, and being flexible about
who sells us the hardware platform to do that, seems wise at this juncture. The
e-media market already has legacy to deal with, and iTunes got out to a
leadership position early in the legacy lock-in game!
This is all very interesting, because this past decade ushered in a
transformative moment for the music, video and book industries, heralding the
movement of personal libraries onto devices. Less stuff being manufactured, less
shipping, less to lug about on the run or otherwise on the go, and less space
consumed in homes. I still like to have a book to deface with my thoughts bled
all over it, but I'm sure I'll come around to the idea I have to let Amazon or
Barnes and Noble own the storage and format for my notes...
The latest "this week on TED" alerted me to the ☼Benoit
Mandelbrot talk at TED 2010. It is really charming! And that led me to ☼Ron
Eglash on African fractals, and it is really interesting and especially so,
when thinking about the implications of fractal strategy--I wonder if this 2007
TED talk inspired Bezos?
3/4/11: Sadly, Benoit Mandelbrot died on October 14, 2010 at the age of 85.
7/6/10 That PICTURE IT...
Ok, so the ☼video of the PICTURE IT
talk is not exactly the stuff of viral excitement, but I reread
the script (what I planned to say) and it makes some points I still think
are worth making... and what's more, they are unique even if I do also point to
the likes of Dan Roam who didn't beat me to the insights but certainly beat me
to print! :-)
Speaking of beating to print, David Sibbet has a book coming out soon--yes,
there are several self-published Grove books, but this one is published by
Wiley, so more likely to reach more broadly and "count" among those who like the
formality of a book and the vetting process that formal publication presents.
Anyway, without even seeing it, I will with confidence highly recommend
Visual Meetings: How Graphics, Sticky Notes
Idea Mapping Can Transform Group Productivity,
will be available in stores August 9th, 2010.
7/6/10 Iterative Development
I drew on reviewers from across the spectrum of the Art of Change
audience base, and each made a big difference to the content and accessibility
of the Report. It really is a testament to the iterative process we all espouse,
to have different people pulled in at different points along the way to provide
suggestions and reflections and move the conversations the material invites
forward. And though I joke about protecting my em dashes, the Cutter editors
were wonderful--gracious but also careful. One area of flexibility on their part
was allowing my Acknowledgments section, but I framed it up persuasively and
they generously allowed that use of half a page. I feel strongly, though, about
the improvement process, and when people pitch in the time to read and think
creatively about how to make something better (and take the time to put their
feedback carefully, so I don't crumple into a heap of slop) then credit and
thanks are due to them.
Now I do want to explain something--mostly to myself! Grady Booch pointed out
that role of the architect in proactively catalyzing and "being the change,
rather than just reacting to it" was implicit, not explicit (in the paper). I
was frankly taken aback, because that is fundamental to our orientation (and
prominent in our innovation and agile architecting paper Getting Past "But,"
for example). I reread the paper somewhat in disbelief--I mean, I took his
feedback seriously because well, he's Grady, but I was also incredulous that he
could be right because well, I'm me! And he was right! Rats! Grin. I later
realized that it was in part an aberration caused by splitting the paper into
the two parts--you see, Part Two: To Lead is to See, to Frame, to Draw is
coming at the 'find opportunity and make it happen" catalyze change thing from a
different vantage point than that covered in Getting Past "But," though
it is still very much about architects enabling their organizations to
be the change! And in part it was just the "what you're paying attention to
shapes what you perceive and pay attention to" disorder that hurts all of us,
and which is why validation/improvement cycles are so important. So I think I
fixed it, and I'm very grateful to Grady and the other reviewers!
One thing I found interesting, and it validates the inclusion of a spectrum
of reviewers, is that each zeroed in on quite different flaws. Wait a
minute--they also all had very nice things to say. So between the good that was
there to begin with, and the improvements, hopefully you'll like it! A lot!
I've had to read it too many times myself, and reading the final proof, I
still see things I'd like to clarify or add (and on occasion take away). But I
also like how it turned out. I even like the Executive Summary, even though it
was murderous killing all those "thought children" to get it from 16,857 words
to 1,100! I just hope you like the Report! Well, actually, truth be told, I hope
you love it. Smile.
I told the kids "1 down, 2 to go" and Sara said "so you'll never be a normal
mom again." Two? No, I'm not planning to split Part II into two parts! Grin.
And because I allowed myself to get drawn into one Report that became two
Reports, the VAP book is very behind schedule but I'm excited about where
that is headed! I didn't tell Sara though.
I read back over a post from last month... and I liked this:
Create a sense that big things are possible, starting right where you are.
Because the big dings that matter are not one narcissistic trumpet call into the
screaming silence of universal indifference, but rather the concert of dings
that is created when many small dings add up to something big, a change that
Like... you know, any self-promotion by Steve Jobs would fall into the "who
cares" category (the universe being indifferent to narcissism) if many, many
people hadn't made Apple products what they are. The leader creates the concert
and ensures design integrity, and is certainly key. And so are the followers.
Heroes are important to our "tribal" cultures, but contrast
this (Tony Fadell) with
Steve Jobs forever changed the course
of media and entertainment distribution when he unveiled his creation, the Apple
I have no doubt that Steve Jobs played a pivotal role--including seeing the
promise in Fadell's idea. I need to find 45 minutes to
listen to this ♫history
of the iPod.
Dana has been reading Eragon and Eldest with the kids, and he
is quite impressed. I've been too busy to listen in, but Dana relays the
nuggets. For example, there's political play around who will lead, and Eragon
swears fealty to Nasuada and Dana observed "when a leader follows, his followers
follow." This is a point we make about architects--when there are multiple
strong leaders on the architecture team, they need to pick a leader to lead the
with a baseball bat). No-one (generally) argues against leading by
example--and sometimes leaders have to set the example of following well!
Dana said something along these lines:
When the savvy leader-seeker is looking for
a leader, they look for a person who has fire burning in them, because their
fire will light fires in others and get things done.
I like that!
7/8/10 Visualizing: Interesting! Scary...
7/8/10 Visualizing: Interesting! Good...
7/8/10 Visualizing Trees: Interesting
Example for Architects!
This is an
important map (The Afghan conflict: A map of possible scenarios) for the
moment in history, but ignoring what side of the issue you land on, this is a
really neat way to pull together what-if scenarios... Yes, of course we use
utility trees--for example to visually pull together the (non-functional)
requirements like this.
As trees (not utility) go, I like this "family
tree" for Schema languages for XML.
7/9/10 Visualizing Ruth: Bother!
Cutter wanted a photo for the Report. Now, photos of me are extremely rare,
because, well, that's the wrong
side of a camera for me to be on (for good reason)! But if Cutter readers
are going to get to see "me" then, sigh, so should mine...
7/9/10 Thing so Fragile
From time to time I've read some of Alistair Cockburn's poems and I've liked
Tribute to Max Golightly is inspired and moving! But tonight, tracking down
something quite other (not a poem!) I stumbled on
There is a
thing so fragile and I love it! It is truly astonishing -- utterly
lovely and meaningful. (I mean astonishing in the "fill with wonder and
Ok, delight. And Cockburn's take on Kano:
7/10/10: I make a bold statement about Thing so fragile, and I wonder
if I should explicate the poem, or my reading of it? Sometimes it is enough that
another person we trust (at least enough to spend time disagreeing with them)
says "utterly lovely and meaningful." So let's try that. Right now I'm quite
interested in poetry that is relevant to architects, and that is one! Philippe
Kruchten's The Tao of
the Software Architect is another. They open
so much for discussion!
7/10/10 Architecture Decisions
Modeling and sharing architecture decisions, Part I: Concepts, Olaf
Zimmermann, Nelly Schuster and Peter Eeles
The Role of Architectural Decisions in Model-Driven SOA Construction (.pdf),
Olaf Zimmermann, Jana Koehler, Frank Leymann
architectural decision models with dependency relations, integrity
constraints, and production rules, Olaf Zimmermann et al, Journal of Systems
and Software, August 2009
Zimmerman's SATURN 2010
presentation slides and his
PhD Dissertation. Other
papers and presentations by Olaf.
ISO/IEC 42010, ANSI/IEEE 1471: Conceptual framework for architecture
IEEE 1471 website
1471 description on wikipedia
Essays in Design, Len Bass
Architecture Decisions: Demystifying Architecture, Jeff Tyree, Art Akerman,
IEEE Software, vol. 22, no. 2, pp. 19-27, March/April, 2005.
Applications of IEEE std 1471
MedBiquitous Software Architecture document
'How We Decide,' by Jonah Lehrer, by Robert Burton,
SFGate, Sunday, February 15, 2009
Some of my take on architecture decisions:
7/10/10 Innovation -- A Great Read!
And to watch:
7/10/10 VAP =d= Agile Architecting
Architecting Process (VAP) applied Agile principles to architecting before it
was even known as
"Agile"!" You just start learning with the cheapest design medium, and
think about which challenges and uncertainties to go after early. Those that
will cost a lot to change. Those that cut across the system, and have far
reaching impact. Those that are make-or-break. Those that will be lived with for
a long time, so we should incur the cost of "quality of life" improvement (e.g.
for the development team, or for user experience) earlier rather than later.
Some will be market related. Some will be
technology related. And code is not the Grail, value is the Grail, so
artifacts that add or shore up value (like architecture models and descriptive
and prescriptive architecture documents, etc.) are peer considerations to code
when it comes to weighing how to invest time/budget/attention/talent. Remember,
when we think in value terms, time invested in enabling many people to be
productive (create more value with less resources), is economically
justified! Everything else applies--iteration, stakeholder participation,
willingness to be wrong and renegotiate the value targeted. Etc.
7/10/10 Nice Words about VAP
and Other Work
My feathers are puffed up by this compliment:
Malan , who is co-author of one of the most brilliant
methods of software architecture - the
-- Marco Mendes,
Visual Architectures blog post, July 4, 2010
So, my action item is to get the VAP/Software Architecture Action Guide book
done already!! Which means I have to clear Part II of that Art of Change
Cutter Report off my plate. Sorry, but
as twins go, that one is kinda cute and I've grown quite attached to it. So
I need to get it finished.
In the meantime, we just learn and learn, and the VAP book is shaping up to
be really exciting!
Oh, right, as compliments go, this was on a Bredemeyer mailing list sign-up
(so relates to the Bredemeyer Resources for
Architects site) last month:
"great website with very well put together
explanations, documents, etc. nice work." -- Stephen
In July, well, there have been even more than the usual number of mailing
list signups, so that's nice. Remember, I view a mailing list sign-up as an
implied compliment, because giving us contact info is a matter of trust and
As for Part I of The Art of Change, I was told:
"It's an excellent Report, and quite
enjoyable to read to boot."
I like that! That is exactly what I'm after--great content, enjoyable to
read. Gosh, I do hope it generates enthusiasm, because I think the ideas are
worth getting excited about! Fractal strategy (Jeff Bezos) and tandem
architecture. IT creates the architecture of the relationship platform, so
determines in key ways the architecture of the business ecosystem. Agility is
reshaped over the product-market lifecycle, with primary change vectors being
driven by "a creative wave of destruction" (Schumpeter) early, and diffuse
ripples of change as product/application variation is driven out. I think/hope
it is a major contribution to how the field sees itself, inviting
conversations... If I can find some moments, I want to put the key ideas into a
Visualization and Architecture Governance
Static analysis of code against architecture rules (such as those implied by
Robertsson suggests expressing the architecture rules in code, to automate
enforcement of architecture rules. He lists these static analysis tools:
Structure 101 helps discover fat packages and classes, and tangled designs.
- Fat -- too much responsibility, too many dependencies on it
- Tangled design makes it hard to change the architecture, because a
Image source: Slide from Magnus Robertsson's
presentation which is on InfoQ.
7/10/10 Design Rulez!
It occurred to me, seeing "Code rulez," that people who have an aesthetic
sense about clothing, for example, pay a premium for design. Right? The
value isn't in just any suit, it is in the cut, the name of the designer that
brings with it style, fabric choice, line, and more. So value does not simply
equate to "raw running code" -- the cheap suit or the designer branded suit on
the shelf are not equal in value. If all we cared about was that "it runs" ok,
we would buy the "cheap suit." That is, we could by-pass explicit intentional
design by talented, trusted experts at design... But we don't generally want the
cheap suit! Design matters. So that the crux of the matter isn't producing a
suit with just any cut, nor just cutting code. We decide what design
considerations add value, and what price point we are aiming at--where the price
is customer cost, yes, but also developer pain, and cost to evolve, as well
customer experience factors... like safety in a car, or availability for online
tax filing... [Ok, I used the example of a suit, but do you buy your jeans from
Walmart? We know that more than a few people do. There is an economic bracket
and use model for jeans that make jeans from Walmart makes sense. And an
aesthetic bracket and use model for which it does not make sense... etc.]
Of course, Magnus is all about architecture-has-value. I appreciate the point
about automating the process of finding deviance from the architecture (and we
have added reference to SDM tools like Lattix into our workshops, drawing
attention to this architecture governance at nightly build step in the process).
And the point about acting with discipline to nip deviations in the bud before
their effect compounds. But instead of saying "code rulez" I'd want to say
"design rulez! Yes, design rules--it constrains (and putting as much as we can
of the onus of "policing" into rules in the code, or into tools that are thrown at
the code, is good). And yes, design rules--we do big things by being
intentional, and explicit design with a healthy dose of design
improvement/validation is intentional.
We design to achieve desired outcomes, including design integrity. Structural
integrity, yes, but more--design integrity.
7/19/10: Which is not to argue for BDUF, but rather explicit, intentional
design--iterative and incremental, in terms of the cheapest design medium for
the design decisions that are the order of the day--in the Bucky Fuller sense of
"what, at this extraordinary moment in time, should I be thinking about?" Early,
I'm looking at what is make or break to get right, including what has diffuse
impact, so becomes harder and harder to change the more code we have cut. But
also, I want to understand the success and fail factors, what will shape the
destiny of the product/market/use concept and meaning, what will shape
structural integrity, what forces will impinge on this system now and as it is
broadened in use/application (or scope) and scale, ... But it's not just a
matter of the cheapest design medium. It is also a matter of human tendency.
When we put working code in front of someone, they work at tuning that--the
mindset is small delta. That's a generalization, of course, but generally once
we are reacting to something concrete, the concrete thing shapes our
expectation, and we tweak that. Instead of having a whole gamut of design
options in front of us, we have narrowed the design space. So early on, if we
really want to be creative, to explore the market and design opportunity, we
need to keep people in the zone of possibility. That is a key message of
Sketching User Experience--informal sketches and paper mockups convey that
the concept is not a done deal; we're still working at the concept level, not at
the reaction to detail level. So early, we want to play (literally, wherever
possible), with concepts, with quite different sketchy designs and mockups. This
helps drive our creativity and keep our circles of design influences and
partners fluid and thinking dynamically about what they value. Then, as we
progress through all the divergent-convergent phases on the iterative and
incremental design, the scope of our attention shifts (sometimes narrowing
focus, sometimes returning to broad scope to refactor given a surprise or
learning) but we need to keep applying this discipline of exploring design
options. And as design decisions are made, and changes to the design start to
bear higher and higher cost because the design is being molded in code that many
minds are wrapped around and many hands touch, we need to bring that under
change control, and that is where the design rulez in tools come in very handy.
That way, we spot deviations from the "rules" inherent in key architectural
design decisions early, rather than once they have becomes "hard cast" in a
growing web of dependencies ... that take a lot of work and destabilize
the system in unpredictable ways when we try to factor them back out.
7/10/10 [10:35pm EST] Eh hum. What about me?
If this was planned, they weren't taking me into consideration! Hmmpf!
Microloans that enable self-employment and upliftment of some of the world's
Competitors (direct competitors, competitors for attention, competitors for
7/11/10 There's Opportunity in
Fonolo was one of Time's top 50 sites last year. What?
It makes the call to that large, impersonal corporation, presses the right
buttons and stays on hold for you until a human comes on the line." -- Adam
50 Best Websites 2009
7/12/10 Directions for The
Art of Change
In The Art of Change (don't sigh, I'm not going to be retrospective
again--more like prospective, actually), I created a model (you'll find it
in table 1 when you get your hands on the paper) of the product-market
lifecycle. My motivation was to create a model to use to talk about how agility
is different, at different points in a large enterprise--the vectors of change
are quite different when creating a concept/meaning that launches a product
which creates a new market space, than the vectors of change associated with
diffusion of the product concept. This includes creating product variation to more closely
meet the needs of more segmented markets, improving product qualities, adapting
to new uses in neighboring market segments, tuning the value stream to make it
more efficient but also through deepening relationships constantly innovating on
the product and the process by which it is designed, manufactured and
incorporated into its various uses. Keith Frampton pointed out that the
lifecycle doesn't address the "other side" of market aging/death (I forget
exactly how he put it, but that is the gist of it). Of course that is a good
point. There are interesting places I'd like to go with the model, as I think it
serves many rich discussions. It certainly invites a much deeper discussion of
agility across the lifecycle. There are implications to draw out further for
product/service/solution strategy and architects, as well as for IT.
Someone kindly suggested that both The Art of Change: Fractal and Emergent
Report and my SATURN tutorial ought to be turned into books. Well, that is
exactly what a writer wants to hear... and whenever someone tells me what I want
to hear, my internal critic shifts into high gear, telling me just that. The
Art of Change: To Lead is to See, to Frame, to Draw is a cut at the same
space of materials and concepts as my Art of Drawing People In tutorial.
It comes at it from a different angle, using a different structural model, but
it's generally the same space of experience and organizing concepts. Anyway, the
encouraging suggestion was to focus on the SATURN tutorial content first. So, I
guess it's good that getting that Report completed is what is up next--for my
"discretionary" time slices...
Still, The Art of Change: Fractal and Emergent Report introduces so
many avenues I would love to explore and till... Likewise with the To Lead
report... So, once you've read both, you can throw the weight of your
encouragement behind the book you back. I wrote the Fractal and Emergent
report to put our voice behind regrooving the way IT and architects are
seen--helping to articulate the role of IT as a strategic (not just a cost)
center of excellence that propels innovation in product and process (IT
architects and implements the relationship platform and instruments processes
and provides analytics to create business intelligence, which are key to finding
opportunities to delight through design that fits aspiration and context,
meaning and... oh bother. Please read the paper; 16,000++ words would be a lot
to rewrite here)... That is an important mission, I think. But as I pursued it,
I think I pulled together a practice-shaping set of constructs and models, and a
book would give more scope for depth of treatment on a number of avenues that
tantalize--me, at least.
Oh yeah. Books. Then people will realize that my journal is full of the most
delicious pieces of wit and wisdom and they'll put quotes on signatures that say
"From which I conclude: half don't like
people to be different and the other half don't like people to change."
Ok. Probably not.
Yes, yes, top of my list of books is the VAP Action Guide book. I need
several lives: one to be a wife and mother that makes me real by being so
very loved, and which
gives me such delightful company in play and on the
of life; one to do the work with architects that teaches, invigorates and
inspires me; one to do the writing that draws me out, and along. They say that
teaching teaches, and it does so marvelously because the audience is other
and smart; but writing does too, because one has/wants to collaborate with
thinking partners--multiple internal voices, co-authors, colleagues and peers,
other authors, reviewers, and anyone who we can engage to enter the conversation
and push our thinking. Oh yeah, remember this:
"As for internal voices, one of
mine piped up with this: "It is very good to have more than one internal voice 'cos
you can get so much more thinking done! Thank you, internal voice. I like that.
Of course, this was prompted by my other principal internal voice wondering if
sane people confess to having more than one internal voice."
So much to write!
More focus on the not, I think!
* Pen to paper? Hmmm... well, I still do--for storyboarding... but that has
to be an expression with a limited "shelf-life."
7/12/10 Late is Better than Dead!
Being late on a ship date may put a real ding in investor confidence--if it
is big and newsworthy, like the Boeing 787.
Boeing Faces ''Pretty Tight'' 787 Delivery Schedule, By Michael Mecham, Sep
9, 2007 and
More delays ahead for Boeing 787? Posted by Guy Norris at 12/4/2008. Why the
" further serious slide would mark the culmination of what has been a miserable 16
months for the manufacturer, not to mention its suppliers and the 787 airline
customers. It all began in September 2007 when Boeing slid first flight to
November/December 2007 due to supplier hold-ups, ‘traveled work’ and software
integration issues." --
More delays ahead for Boeing 787? Posted by Guy Norris at 12/4/2008
Sounds like software is getting hit by the blame bus again and that would be
worth ferreting out. In the meantime, the first delay was hardware--'the need to
reinforce a "side-of-body section" of the composite fuselage',
787 First Flight Delayed For Several Weeks, Jun 23, 2009
But I like this commentary:
did the right thing. You know why?
least with respect to the 787 is run by engineers and in their minds, the
schedule NEVER dictates when a new planes flies. Airworthiness does. Two of the
top three decision 787 makers are engineers with advanced degrees." --
Boeing’s Candor on 787 Delay By John Dodge | Jun 23, 2009
I hope that all this focus on risk and safety
brush-offs in industry after industry will teach us that we need to follow the
architectural principles laid out the good old Constitution of the USA!
Remember--separation of powers and checks and balances. Why? Because power
corrupts. Madison knew that. He
learned from history*. So, while we need project managers who pay attention to
resources and schedule, we need architects among the critical decision makers
who are charged with system integrity and empowered accordingly. Empowered to
assemble the knowledge so they know the market and technical risks, and can
weigh these, and empowered to weigh in on decisions that affect risk and
* but ultimately succumbed to corrupting forces...
Since you aren't following me/my software visualization list on Twitter,
sigh, I'll give you a heads up anyway. Grin. I added these to the
Visualization in Software page:
Visualization of metrics and areas of interest on software architecture
diagrams, dissertation, 2010
Duszynski, S.; Knodel, J.;
Lindvall, M. , SAVE: Software Architecture Visualization and Evaluation,
13th European Conference on Software Maintenance and Reengineering, CSMR
2009. Proceedings : Architecture-Centric Maintenance of Large-Scale Software
Systems, March 24-27, 2009
[Good stuff coming out of Fraunhofer around the SAVE project.]
Ghanam, Yaser and Carpendale,
A Survey Paper on Software Architecture Visualization, 2008
Please remember to let me know what tools you like to use, to help your teams
get a handle on the code base, or to manage compliance with the
architecture/spot deviations from it early. Etc. I and the community (at least
those who value the
visualization resources page or
Twitter list) will thank you.
Worse Than My Journal?
I've unfollowed several people/lists that I
was following just because they are so
busy on Twitter. I was close to unfollowing Martin Fowler, because, frankly,
I'm sorry to say... I don't really care when he's landed. But then he tweets:
"The true sign of expertise is
that the more you learn, the less you feel like an expert. Or at least I hope it
like replying to say "Oh, can I use that? That's so much better than 'the older
I get, the more humble I feel...'" [Though both refer to the same thing: the gap
between what I know and what I want to know only grows the more I learn.] Or... I could point him to my take on the
specialist/generalist joke (which I recast in terms of technical specialists
But I wouldn't want to draw attention to myself
that way. Grin.
Anyway, I think "goodness, for such
pebbles, I'll continue to scout
pebble-strewn beaches." Um... That's why you're reading here right?
Like the last paragraph in the
Late is Better than Dead post... isn't
that in the category of the pebble that is
Dana was again telling me about Paolini's Eldest, and characterized
what was happening as a "leadership moment." I'm going to have to read that
chapter, so I can portray it accurately, but the part Dana told and the part I
heard him read is very
To Lead is to See, Frame and Draw! The leader saw that the current
situation was untenable, searched for what to do, convinced himself that the
really hard thing must be done, raised in himself the passion and the
inspiration to play the leader--to give an impassioned speech and set the
vision, be compelling and very graphic about the risks and consequences of not
taking the course of action, but also being frank about the risks inherent in
taking the route he laid out. He recognized that a compelling reasoned argument
full of logic was not going to get the village to take the only course open to
them (other than the course of inaction--which was to be doomed without doubt).
Instead, he knew that he had to appeal to them at an emotional level. He rose to
the challenge he set himself, and the next day was surprised to see that he was
being treated differently, with the respect due a leader. By his previous
actions, he showed himself credible and fit to lead, and he laid out the path to
be taken. He stepped into the role, onto the plate of leadership, and others saw
that by his action and his vision, he was the leader to get them where they
needed to go. Interestingly, Paolini then has him look at his reflection, and
see that he looked the man to lead.
Aside: The title is
To Lead is to See, to Frame, to Draw because I use a fractal-inspired
unfolding for the structure of the Report. But it does make for a lot of "to"s...
7/13/10 Positive Thinking -- Good for the Brain!
Look at the quote on the cover of this book:
The Brain That
Changes Itself. I guess I'll have to look into it!
"The discovery of neuroplasticity, that our
thoughts can change the structure and function of our brains, even into old age,
is the most important breakthrough in our understanding of the brain in four
7/13/10 International Harp Competition
We're all taken with harp this week, for it is the
USA International Harp Competition and we have
leading harpists from around the world competing and it is so magnificent! It is
an instrument with so many different voices, and to have such stunning talent
come to us is quite marvelous! I do love Bloomington--we have an amazing
music scene. It is very inspiring for an aspiring harpist like Sara to hear such
talent from around the world at the very university where she is in the
pre-college harp program!
7/14/10 The Education of the
follows, therefore, that architects who have aimed at acquiring manual skill
without scholarship have never been able to reach a position of authority to
correspond to their pains, while those who relied only upon theories and
scholarship were obviously hunting the shadow, not the substance. But those who
have a thorough knowledge of both, like men armed at all points, have the sooner
attained their object and carried authority with them.
3. In all
matters, but particularly in architecture, there are these two points:—the thing
signified, and that which gives it its significance. That which is signified is
the subject of which we may be speaking; and that which gives significance is a
demonstration on scientific principles. It appears, then, that one who professes
himself an architect should be well versed in both directions. He ought,
therefore, to be both naturally gifted and amenable to instruction. Neither
natural ability without instruction nor instruction without natural ability can
make the perfect artist. Let him be educated, skilful with the pencil,
instructed in geometry, know much history, have followed the philosophers with
attention, understand music, have some knowledge of medicine, know the
opinions of the jurists, and be acquainted with astronomy and the theory of the
Vitruvius, The Education of the Architect, in
The Ten Books
7/15/10 The Art of Change Free
Download is Here!
Ruth Malan and Dana Bredemeyer, "The Art of Change: Fractal and Emergent,"
Cutter Consortium Enterprise Architecture Executive Report, Vol. 13, No.
Here are the
papers we have written for the Cutter EA Executive Report series in the past:
Architecting process (innovation and agile architecting):
Malan, Ruth, and Dana Bredemeyer. “Getting Past ‘But’: Finding Opportunity
and Making It Happen.” Cutter Consortium Enterprise Architecture
Vol. 11, No. 8, 2008,
Bredemeyer, Dana, and Ruth Malan. “What It Takes to Be a Great Enterprise
Architect.” Cutter Consortium Enterprise Architecture
Vol. 7, No. 8, 2004.
Malan, Ruth, and Dana
Bredemeyer. “Enterprise Architecture as Strategic Differentiator.” Cutter
Consortium Enterprise Architecture
Vol. 8, No. 6, 2005
classify "The Art of Change: Fractal and Emergent" under architecting
process-certainly it has particular relevance to the architecting process, as
well as how to set up the role, organizationally.
Yes, to download them you must either be a
Cutter client or download them from the links above, which means you can
download them free, save for the price of giving Cutter your contact info.
But remember these are highly "pedigreed" reports, selected and edited with
stringent standards of excellence. ;-)
7/15/10 Why to Believe in Others
Stroe pointed me to this clip on TED:
Viktor Frankl: Why to believe in others. 1972. That was some point in
American history! To put it in perspective, that was the year Steve Jobs -- and
Dana Bredemeyer -- graduated from high school.
I think there is a great essay to be written about the
generation coming of age in the 70's--or perhaps to be read; do point me to it
if you've come across one. These were the years when students flocked to listen
to an aging Buckminister Fuller hold forth... It was the age of possibility and
the age of hope; an age when young people asked big questions.
Kind of like today, huh? :-)
I need to think more about Frankl's message
and illustration though...
Apple Embarrassed by Consumer Reports...
'The reception issues prompted
Consumer Reports to say it
could not endorse
the phone, a fact that Jobs said
July 16, 2010
Jobs returned from his vacation in Hawaii to face the storm... So, the question
I have is--did Consumer Reports test other phones in the same way they
tested the iPhone 4?
7/19/10 Framing Forces and Trends
This McKinsey article frames the importance of thinking about trends and
forces that will shape the competitive landscape. Here is the framing used to
launch the article on the "five crucibles of change" that will restructure the
“I never think of the future,” Albert
Einstein once observed. “It comes soon enough.” Most business managers,
confronted with the global forces shaping the business landscape, also assume
that their ability to sculpt the future is minimal. They are right that they can
do little to change a demographic trend or a widespread shift in consumer
consciousness. But they can react to such forces or, even better, anticipate
them to their own advantage. Above all, they ignore these forces at their peril.
Business history is littered with examples
of companies that missed important trends; think digitization and the music
industry. Yet this history also shines with examples of companies that spied the
forces changing the global business scene and used them to protect or contribute
to the bottom line.
... Today, when the biggest business
challenge is responding to a world in which the frame and basis of competition
are always changing, any effort to set corporate strategy must consider more
than traditional performance measures, such as a company’s core capabilities and
the structure of the industry in which it competes. Managers must also gain an
understanding of deep external forces and the narrower trends they can unleash."
Global forces: An introduction, Peter Bisson, Elizabeth Stephenson, and S.
Patrick Viguerie, June 2010
I liked Gladwell's
article on innovation, and the notion that key inventions are
"in the air" at a point in time, about to be plucked by one or several
inventors, innovators or scientists at the same time. Another way of putting
this, is that forces are shaping up, histories and knowledge has aligned just
so, and the "fruit" of these coming together is in reach of the creative person
who is thinking about what next. You don't have to be thinking about the whole
of the future! Just what's next in a slice of the future, given what we
know now. Because someone else will, and they will shape the
future with or without us!
7/19/10 It Would be Nice...
If you like "The
Art of Change: Fractal and Emergent," please let others know how to get hold of
it -- by downloading it free from:
http://www.cutter.com/offers/artofchange.html. For those who'd like an
here is a synopsis.
7/19/10 Re-imagine This!
I see this
visualization of dependencies, and think of applying the concept to software
visualization. Of course. :-) [This is just a table, but by pulling it
over on an arc, we can see the whole at once, in a limited space. The column
headings are left along the top. It's a neat idea.]
Visualization is very much a matter of how much to put on one visual model, to
convey with clarity and to provide a tool for analysis/thinking/communicating,
rather than obfuscating.
So, what are our concerns (e.g., inter-component dependencies and coupling,
responsibilities and cohesion, tracing concerns, etc.) and how do we
elevate these as visual elements so we can grok what is obscured in or hard to
sift out from the code?
7/19/10 Visual -- Misc
Empathy Maps (you might want
to relate these to Desired State Interviews, Stakeholder Profiles, and the
lesson from the stork in The Wheel on the School (see
"But": Finding Opportunity and Making It Happen)
How Google Maps keeps Innovating, sketch notes by Kate Rutter and
sketch notes of the same presentation by Eva-Lotta Lamm
Free the Facts, by Dave Gray, XPlane
The Value of Getting Visual in Social Business, David Armano (see slide
19, 20, 22, 23, 28, 32, 55, 57)
[wrt slide 57, I was struck by this:
"People often ask me how long I’ve been drawing, but the answer is that I’ve
never stopped drawing. For most people it is not about when did they start,
but rather, when did they choose to stop."
Kevin Chen, in an
interview by Kendra
Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform
Group Productivity, by David Sibbet, August 2010
resonate: Present Visual Stories that Transform Audiences, by Nancy
Duarte, September 2010
slide:ology: The Art and Science of Creating Presentations … by
7/19/10 Innovation Misc
7/19/10 I Want One!
I was thinking that a neat design goal is that "I want one" kind of reaction!
It occurs to me that these two snippets are points on that path to "I want one"
as driver for stories" from visual sketch notes by Eva-Lotta Lamm on
Scott McCloud's talk at UX2009
that matter--memorable moments to punctuate experience," sketch
notes by Kate Rutter Exposed Conference : Sketchnotes, Breathing life
into buildings, p2
Why? Because we want products/services that enhance meaningfulness, and stories
are how we make meaning--in our conception, we figure out what the object or
experience of desire is, we tell stories about it, we build it.
See -- I want one!
7/20/10 Exposing the Invisible
Here's a nice analogy to push our thinking about software visualization:
Exposing the Invisible. TED Talk 2009
7/20/10 MacPaint Source
This great news by way of Grady Booch's blog:
QuickDraw source code is now available on CHM. Pascal! This is one of the
reasons I think that great code is like great poetry--you have to work to
understand each, because the form is sparse, but as you do, you gasp at the
beauty of the encounter and the mind that made it!
There's also the oral history:
Atkinson and Andy Hertzfeld, MacPaint Oral History conducted by Grady Booch,
2004, Computer History Museum; transcript
7/20/10 Code Metrics and Architecture
7/21/10 Details That Matter
Architects Need to Code post from 2007 got blogged and tweeted in May, I was
struck that that was the topic, of everything that I've written, that got so
much interest! Well, of course there are strong opinions--there is nothing like
getting one's "hands dirty" to know that section of the system. Still, don't we
want the architect to know the system? Now, for a small system, staying intimate
with the code is one thing. And its quite another to be intimate with 1
million LOC! So that's where code visualization tools like NDepend come in
really handy. But static analysis only takes us so far. I mentioned Tracer
back in May. Has anyone looked into it? I'd love to know what you think, and
what you use to grok and see the evolution of not just the static structure
of the system, but how it works.
On his email signature, Mark Lane (President of the
CAEAP) has the following:
"A Enterprise Architect must not only see the forest but also know the
A system architect must not only see the trees,
but know the mushrooms and other delicate flowers and structures. But when we get to
the small details, they are thematic. By which I mean, we can't possibly pay
attention to each and every detail, so we have to learn how to look, and
what to care about. And the looking is important. And I cycle
back to Agassiz and observation. And "the pencil is the best eye." That
is such a profound lesson! A camera is pretty good, because it gets us to
look differently, to see detail and lighting and structure/composition
differently. And a pencil is wonderful, because to draw something, we really
have to see it--in our mind's eye, if we're designing. Yet drawing it out,
drawing in the details that matter given what we're going after, and leaving
off others, we see more, afresh, keenly. Dana asked me to help him find a
bug in a piece of code he was writing, and he'd narrowed it down to a
section of code, but just couldn't see it. Well, I couldn't either. It
wasn't in the code. I asked him to draw what he wanted to happen for me, and
as he did, he realized an assumption he was making. He probed, and indeed it
was an assumption about a boundary condition. That's why I said it wasn't
in the code. We make these assumptions, and often we don't even realize
we've made them--it's that blink intuition stuff that goes on preconsciously.
And drawing and explaining and discussing, helps us draw these out. That's
true at the system level, and it's true in the details of the code.
"inspiration a gift, returned and yet kept"
-- moi, Tides That Move
7/23/10 Weaving Ruth
The other night
I was challenged to list my "favorite 3" journal entries, and the
point of the challenge was if I can't recommend "favorite entries" in
this journal, I can't expect it to generate buzz, and perhaps I should rethink
the style and content. It is kind to be concerned, and I much appreciate that.
My first reaction was that that isn't the point. I try to look past defensive
first reactions... Still, I have raked over this value/form and format turf (too
often) already, and have (tentatively) concluded that I shouldn't discount the value this
journal has to me, being part idea-sandbox and part travel-log of my exploration
through the territories central to and neighboring on all that is significant to
being a great architect. And beyond that, it is more as a flow rather than as
isolated entry that I expect there is value... As for word-of-mouth, isn't it
possible to say "if you want to explore in the neglected areas of our field--the
areas neglected that is, by the mainstream of our experience as a developer and
up-and-coming architect--then this is one fine scout to check in on from time to
time"? Or something like that.
Possible, but not likely.
If I was asked, instead, to pick 3 representative entries, these might feature
Delight and curiosity. Humor and humanity. Courage and advocacy.
Courage and advocacy. Well, I confess, not so much
courage--I keep this a quiet backwaters place. There's the veil of words. And
there's the metaphoric photos of entryways and flowers, and pictures of
children. The "Q<= writes here" voodoo warnings that hopefully keep those
with no sympatico with my style and predilections from stopping off here. Oh,
right, and poetry. Gosh, no poetry (references, but no quotes) yet this month. I'll have to fix that! How about
may came home with a smooth round stone
as small as a world and as large as alone.
-- ee cummings, maggie and molly and millie and may
You can listen to it here: ♫Eric
Whitacre's composition and here: ☼Natalie
Merchant's♫. Comparative listening. We learn
so much through alternatives, don't we? And yet in the rush to code, the forward
rush of "sprints," we invest so little in developing or finding them. The
architect has to say "fast here, and not so fast here." Sometimes
the best way to move forward is to move laterally first, and sometimes we have
to backtrack. So, we try to do as much
scouting as we can as cheaply as we can. [It is silly/naive, don't you
think, to foist all this onto the process, not the
experience and good judgment
What we see depends not only on what we look at, but where we look from, and I
look from a different place than you. Not everyone values
that. But I do. I learn so much from the "otherness" of others. Similarities and
points of contact that validate what I do and think, but differences that
enhance and stimulate new syntheses and
I came across the term "brain crush" the other day
(specifically, “Adaptive Path has a
brain crush on
Dave Gray') and I
like that! Hmm, let's see, at the moment I have a brain crush on Tim Brown (I'm
reading Change by Design), I've long had a brain crush on the likes of David Sibbet
and Eb Rechtin and the lineage of many of my thought children trace to
the recognized fathers of the fields I work in. But when it comes to thought
children, I'm afraid I'm quite promiscuous. I ruthlessly (or ruthfully) pursue
Brian Zimmer because to me he is the engineer's engineer, the architect's
architect and the (geek-) artist's artist--the combination of which makes him
one of my architect heroes. I have many, but I can't point to most of them
because they are hidden behind NDAs and have no public persona. People impact
us, in big ways and subtle ways.
Eric Whitacre's personal
story of the impact of his teacher on his life is deeply touching:
"I often think how lucky I was to have
stumbled blindly to the place where David was teaching, and in retrospect I am
struck speechless at the thought that our paths might not have crossed. Were it
not for Maestro David Weiller I would have had a drastically different life, and
it is to him, with infinite love and overwhelming gratitude, that I have
dedicated these works."
the story of
Athena and Arachne in the context of kiviat/spider diagrams (and my sketch
of archman making tradeoffs among qualities with "only so much rope"--that last
is a reference to
Dan Pritchett), but the story has
particular relevance to giving credit**. The myth of Athena and Arachne, the web
and weaving, reminded me of
this post, and weaving a magic carpet of the dreams of the team. And giving
credit. How I do cycle! But it is something we perennially have to deal with as
architects! One way to lead, is to give direction and shape to, provide context
for, the creativity of the team, so that being so empowered, they make something
great but they do so as if without strong reigns to give direction, no
forcefully wielded baton, no high command. That is the way of the
Tao as reflected by Kruchten. We can't do that
and overtly, persistently, "mark
the territory," in dominance hierarchy, credit-claiming terms. The polar
alternative is to take the credit and the flack, the way Steve Jobs ostensibly
does. That is more the leader as mythical god:
came to me the figure of Alexander the Great. His ding is enormous and his
figure served an example for generations since. His empire was ephemeral, still
it brought tremendous prosperity through opening new markets and facilitating
exchanges (including Afganistan which had an Hellenistic culture surviving a
long time after Alexander). A leader that was perceived as god, a common
practice in Rome and a way that an empire - a human construction - is held
together. Once such beliefs evaporate, such constructions will decay, like the
corpse after soul's departure. Such beliefs are given by the many and maintained
by the leaders through qualities, PR and propaganda / branding. Today we do not
perceive anymore leaders as gods, still there is enormous reverence or hate
-- Daniel Stroe,
personal email, July 15, 2010
Alternative leadership styles. Or something in between. I love the recognition
in that "the way a human construction is held together." Software is a
collective workproduct--the system and the team that creates it are human
constructions. What holds the team together, directs it, gives it meaning, is
what gives the system coherence and integrity. What is that? A shared
conception, a shared dream.
And so we weave, and the lineage of what we weave traces back to tellable and
untellable sources, and where we can tell the source we should!**
Returning to Whitacre. There is an important lesson and striking humility
and frankness in
Eric Whitacre's account of his composition for Three Songs of Faith
and in particular I thank you God for most this amazing day. It isn't a
story of attribution, but it is a story of the fallibility of intellectual
pride, and these things are related.
Dana just got back from teaching our EA workshop in
Chicago. His flight up was delayed. His luggage only arrived at 3pm during the
first day of the workshop. So the first day he taught in shorts and a Hawaiian
shirt. He went with a beard, but shaved it off on the 3rd day. People in the
class asked if this was something he usually does. No, actually--he doesn't
usually start teaching in shorts sporting a "been hiking/camping" beard, then start
to dress more business-appropriate, then shave, etc. But Dana can
pull it off. He barely turned the projector on--couldn't the first day because
the cables were in the checked luggage that United so kindly delivered about 18
hours after his 30 minute flight from Indianapolis had landed... When I
began my SATURN tutorial, I used the opening lines from The Emperor's
Club--"the end depends upon the beginning." I'd used those opening lines
once before. Both times the technology barfed. Somehow, things go wrong, and if
we stay resourceful, the end depends in surprising ways on the beginning.
The common saying is "if life gives you lemons, make lemonade," but it strikes
me that life tossed lemons at Dana, and he juggled them. (Dana is
multi-talented--he can ☼juggle, ride a
unicycle, play the guitar and sing, has
taught kayaking in the San Francisco Bay, writes more code than words, talks
about Rumi as comfortably as algorithm design, etc.) Ok, so the end depends on
the beginning, and it helps, at the outset, when there are high (but appropriate)
expectations. In this case, the architects had either read our Cutter papers and
cruised our website or they work with peer architects and managers who
unequivocally say that our workshops have been the most transformative class of
their career. Imagine a class that is transformative! There are lots of
software/tech classes that teach. A workshop that you recommend to others
because it transformed and enabled you, is something well beyond that. So, you
see, I am very proud of our Dana! And there is something important, in that
story, about credit or attribution. Not only is it rewarding for us to hear that
our work was transformative (if we didn't get to hear that, our work would have
little objective, external validation of its significance), but it was important
to the experience of new generations of architects encountering our work. The
attitude we start out with, affects our openness to experience and learning--of
drawing forth from within, and changing mental maps--adding to, shifting,
And so these things cycle. I am open to learning, I engage with experience and
thought and the thinkers who think them, I take in what you offer me. Weaving. And unlike Arachne, I do try to give
credit to my teachers, but there are so many, and the excitement of making the
new weaving sometimes carries me, and I'm careless. Dana foremost
fills me with ideas,
some his directly, and many that trace their lineage to something he shared. Of
everyone I e-converse with, Daniel is the most wonderful scout, for he is
incredibly generous in sharing his quests and they range where I wouldn't
otherwise think to go! Others are too. But, well, that's what it's all
about--collaborating dynamically and asynchronously so we enable more and more
in the world. Creating awareness: we've gotten this planet into such deep trouble!
Creating ability: complexity and the need to collaborate to handle more and more
sophistication in the intellectual products--designs--we create. We can navigate
our way through the so-quickly massing piles and piles of facts, or we can
collaborate in the navigating and the meaning-making, to enable great, wonderful
accomplishments that ever push what mankind can do, and hopefully, by developing
a real sense of community and shared destiny on this troubled "spaceship earth"
(a Bucky Fuller term),
we can turn the trajectory around and head for better!
may came home with a smooth round stone
as small as a world and as large as alone.
for whatever we lose (like a you or a me)
it’s always ourselves we find in the sea
-- ee cummings, maggie and molly and millie and may
Natalie Merchant gives an interesting perspective.
too. The back-story is so interesting! And it's sad that we don't
think to keep better account of the
back-story to systems and their architecture. But this journal is where I
trace my back-story. A trace of my journey as I romp and roam within others'
thoughts and constructions, and my own. Daniel, referring to
Samuel Pepys' diaries, asked
why I journal. I replied "I write to engage."
To engage myself, and others--the
rare others who care to be so engaged, that is. To engage with the great dragons
and demons and sprites and angels of ideas. Daniel replied:
like your "write to engage," is this ludic openess? Or socratic shepherding?'
Well, both, of course, and more, my
dear man. But I do so like how you put it!
The backstory. Dana told me the story of the HP 250,
and a wonderful book the team had made that documented it. I wish we still had
So, head crush. Is that a very
Q<= way to put the admiration we feel for someone who's thinking, exploring,
creating we admire? Well, just to be clear, I have more than a head crush on
Dana Bredemeyer--I have a serious heart crush too. :-)
** I try to do that. If ever
you feel I've slipped up, do please tell me! Or if I should reference something,
but have neglected to/just not seen that opportunity, tell me! It is not just my
role but my deep orientation, so just assume it was an unintended oversight.
7/23/10 Upcoming Workshops
Dana Bredemeyer will be teaching two open enrollment Software Architecture
Workshops in Europe (both classes will be in English):
Yes, we'll hold an open enrollment workshop in the US in late October. And yes,
I'll likely teach that. Well, at least that excites me!! :-)
7/24/10 I Want One! NOW!!
Oh wow! Have you seen Note Taker on the iPad? Way to go
Dan Briklen! :-)
I see that
Ivan Sutherland's SketchPad PhD dissertation has been republished. Bear in
mind that was completed almost 50 years ago.
Ok, now model recognition if you please.
7/25/10 Coupling and Cohesion, Modularity
W. Stevens, G. Myers, L.
Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139,
Pressman, Roger S. Ph.D
(1982). Software Engineering - A Practitioner's Approach - Fourth
criteria to be used in decomposing systems into modules – David Parnas
“Reliable Software through
Composite Design” by Glenford Myers (http://www.amazon.com/Reliable-software-through-composite-design/dp/0884052842)
The Practical Guide to Structured Systems Design, ch 6,
Steve McConnell, Code
Loose Coupling is Good (2/25/2009) and
Zen and the Art of Loose Coupling (4/8/09) blog posts
Design Pattern Principles for ActionScript 3.0: Loose Coupling, March
Loose Coupling Principle
Doug Kaye, Loosely
Coupled: The Missing Pieces of Web Services
Karl Banke, Dirk Krafzig, Service Oriented Architecture: Inventory of
Distributed Computing Concepts,
3.5 Tight Versus Loose Coupling (excerpt from Enterprise SOA:
Service-Oriented Architecture Best Practices) Dec 10, 2004
coupling and cohesion
Cohesion, Kent Beck
and Cohesion, Jeremy Miller, Microsoft Patterns in Practice
Principles of OOD, Bob Martin, and
Agile Principles, Patterns, and Practices in C#, Robert C. Martin and
Micah Martin, 2006
Reducing Dependency in Your Code, Tim Ottinger, Jeff Langr
Cohesive Software Design Cohesion makes code easier to understand, debug,
and test, Tim Ottinger, Jeff Langr
(cunningham and cunningham--c2 wiki-- great source of references and more)
Intramodule cohesion and Intermodule
coupling, UNC, COMP145
why coupling is always bad, Vidar Hokstad
coupling and cohesion, Joshua Engel
connasence and rule of locality (e.g.,
notes on Jim Weirich's Grand Theory of Software Design on Andrew Wang's
coupling and cohesion metrics
strategies and patterns to achieve loose coupling
(loose) coupling -- other kinds of systems
Sciences of the Artificial
"Educational organizations as loosely coupled systems",
Administrative Science Quarterly, 21 (1976), 1-9 (part).
"The Management of
Organizational Change among Loosely Coupled Elements" (1982) by Karl
Weick reprinted in his book Making Sense of the Organization
James Douglas Orton
and Karl E. Weick,
Loosely Coupled Systems: A Reconceptualization,
Academy of Management Review 15 (2)
responsibility driven design
Brian Wilkerson, CRC paper, OOPSLA 1989
and Kent Beck, CRC paper, OOPSLA 1989
"Object-oriented design: a
responsibility-driven approach" by
Rebecca Wirfs Brock and B. Wilkerson, Conference proceedings on
Object-oriented programming systems, languages and applications,
Design: Roles, Responsibilities, and Collaborations By
Rebecca Wirfs-Brock, Alan McKean, Nov 8, 2002
presentation files you can download at
Brock and Alan McKean, ObjectDesign: Roles, Responsibilities
Kent Beck, Ward
Laboratory For Teaching Object-Oriented Thinking
sections of Michael Feather's Working with Legacy Code
modularity in software
Architecture book draft, Kirk Knoernschild,
Kirk's blog and OSGi
Agility, Modularity and Architecture's Paradox
- The Impact of
Component Modularity on Design Evolution: Evidence from the
Software Industry, by: Alan MacCormack, John Rusnak, and Carliss Y.
Baldwin Published: January 24, 2008
Exploring the Structure of Complex Software Designs: An
Empirical Study of Open Source and Proprietary Code, by Alan
MacCormack, John Rusnak, Carliss Baldwin, 2005
Modularity as a portfolio of options, Neeraj Sangal, 6/14/2010
Modularity parable and software, Neeraj Sanga, 5/15/2010
Modularity and what we can learn from Trek, Ruth Malan,
Modular programming, wikipedia
modularity in product architecture
Modularity in the Design of Complex Engineering Systems, Carliss
Baldwin and Kim Clark, 2004
Design Rules, Vol. 1: The Power of Modularity, by Carliss
Y. Baldwin and Kim B. Clark, 2000
Controlling Design Variants: Modular Product Platforms,
by Anna Ericsson and Gunnar Erixon
Creating Modular Platforms for Strategic Flexibility by Ron
The Power of Product Architecture Innovation: Modularity,
Integrality and Competition, by Sebastion Fixson and Jin-Kyu Park,
2006 [bicycle drive train example]
- Modularity assessment of product architecture: Implications for
substitutability and interface management, Juliana Hsuan Mikkola,
Product Networks, Component Modularity and Sourcing, Anupam
Agrawal, 2009 [see references for more]
- Refactoring: Improving the Design of Existing Code By
Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts,
refactoring, c2 wiki
refactoring, Martin Fowler's bliki
Refactoring Part 1: A general introduction to refactoring.
Eberhard Wolff interviewing Martin Lippert
factoring/refactoring in the large
[perhaps we should say functionality preserving, rather than
preserving... e.g., we're good if the refactoring allows us to scale
up to the next plateau, but not if it breaks a use case/user story... or
if we refactor to improve fault tolerance... etc. Alternately put, we
can still do the "what" and we should have improved the "how well."]
dependency injection/inversion of control
interfaces and roles
information hiding and encapsulation
case studies and examples
Technical Debt -- Definitions and Resources, Brad Appleton, 23 June 2009
DesignStaminaHypothesis, Martin Fowler
Metaphor, Ward Cunningham, 2009, and
The WyCash Portfolio Management
System, Ward Cunningham, March 26, 1992
- Design debt, Refactoring to Patterns, by Joshua Kerievsky
- Technical Debt,
Quantifying the start afresh option, Israel Gat, Cutter blog March 22,
Technical Debt and Design Death: How to ensure you can deliver
business value in the future as well as in the present; by Kane Mar and
Michael James, 23/7/2006
Managing Technical Debt - a whitepaper, by Steve McConnell (requires
registration, which is free, but also see the blog-entry
10X Software Development - Technical Debt) [via Brad Appelton]
Design debt economics: A vocabulary for describing the causes,
costs, and cures for software maintainability problems; by John Elm,
IBM developerWorks, June 2009
- Managing technical
debt, Tom Brazier, Feb 2007
tools -- static analysis (most focus on modularity, coupling, granularity, etc.
issues and have implications for making technical debt visible)
tools - performance analysis (useful in making aspects of technical
debt visible, like code coverage)
In the work we do with architects, I have assumed the foundation is there, but I
wanted to have some level-setting background material for those who need it.
7/25/10 Design Thinking
Kent Beck's Responsive
Design Lessons So Far (listed as "The Tour") is awesome! And guess what--one
of the lessons is "play with pictures"!
With pictures! It's not only this Q<= who
☼talks in terms of pictures!
Oh, right, I do so because I want to include group graphics, rich pictures, ad
hoc diagrams, and models--UML models, SysML models, analytical models, etc. Yes,
the good stuff of Visual Architecting.
There is a "palette" of diagram types in
this post. It's a nice
idea, and links to my BI pyramid model (that leverages/refers to David Sibbet's
I mentioned I'm reading
Change By Design--it's been on my reading stack
for months, but I was too busy writing about design thinking to read Tim's
book!!! Oh well, I'm reading it now. I love the story he starts with. I noticed
right off (I scan the pictures first, what can I say) that he has a diagram that
is our "circle of innovation" model, just labeled "desirability," "feasibility,"
and "viability" with arrows instead of circles. Kent Beck uses a three legged
stool instead. We have a client who has done the same (used the stool image, that
is). Well, of course Tim Brown has a section on visual thinking. I like
this point: "drawing forces decisions."
And a section of getting our hands dirty, namely prototyping--building to think.
You might remember that I've pointed to Tim Brown's talk on
creativity and play. The really neat thing about Tim's book is that it is
full of stories.
Kent Beck's Write your
own fan letter rivals
Amazon's "write your press release before you start," and Jim Highsmith's
Design on a Box (I've called it a "cereal box vision" after Luke Hohman's
game in his Innovation Games book). If you've followed along (e.g.,
attended a workshop, read Getting Past "But", looked at our VAP posters, looked
at our Action Guides, read this journal, or
etc. Grin), you'll know that we like to use a derivative of
Grove's Cover Story Vision graphical facilitation chart and format. It
the good stuff of group graphical facilitation, and there are the dimensions of the "voice
of the customer" (what great things users, buyers, folk in the value stream
are saying) and the "voice
of the business" that are important to capture, to make the vision
compelling and vivid to various stakeholders and also to establish the charter
for important things that need to be done in the system and its architecture.
(It is hard to get to the big value delta in architecture/design unless we are
clear that there are goals that we will make haphazard progress toward by trial
and error and without explicit reflection and intentional design.)
Still, the fan letter is minimalist and agile, and a good way to get the first
level of buy-in to your idea, so you can get the broader input you need to
create the level of vision that will inspire and align a multi-functional
Getting Past "But"
July is a month for
celebrating and remembering several people who touched me deeply.
7/28/10 Some Interesting Numbers!
"Legacy code amount
1990 there were an estimated 120 billion lines of source code
being maintained (Ulrich, 1990).
In 2000 there are
already about 250 billion lines of source code being maintained,
and that number is increasing (Sommerville, 2000).
An average Fortune
100 company maintains 35 million lines of code (Müller
et al., 1994).
These companies add
in average 10% each year only in enhancements (Müller
et al., 1994).
As a result, the
amount of code maintained doubles in size every 7 years (Müller
et al., 1994).
Older languages are
not dead. E.g. 70% or more of the still active business
applications are written in COBOL (Giga Information Group).
There are at least
200 billion lines of COBOL-code still existing in mainframe
computers alone (Gartner Group)."
-- Jussi Koskinen,
Anyone seen an update on numbers like this?
For example, this is a pretty
old number (from the start of my career -- that's an old number!):
software maintainers have shown that approximately 50% of their time is
spent in the process of understanding the code that they are to maintain
(Fjeldstad & Hamlen, 1983; Standish, 1984)."
-- Jussi Koskinen,
Software Maintenance Costs,
I need to scout for more up-to-date numbers -- if you of know of any, please
let me know!
7/28/10 Hard to Catch
It is better to watch herons from the kayaks than to photograph them, since
it is hard (for me anyway) to hold the camera steady enough (on somewhat choppy
water) for the amount you have to zoom in on these rather timid birds. But,
of course, that hasn't stopped me from trying. :-) (And no, I haven't
braved taking my SLR out on the kayak, though I'm getting there.)
Hobie mirage drive kayaks are not graceful and elegant like a (traditional) sea kayak, but they do make for
a great workout and like minivans, they are kind of the family compromise
transport. They are very stable (and being leg powered, use the strongest muscle
groups), and even when Sara was 2 or 3 years younger (so
7 or 8 years old) I wasn't worried about her being alone on her Sport (that she
inherited from Ryan when he moved to the more graceful Revolution). We can cover
pretty good distances, though last time we were out with the kids, I spent a
good bit of the return trip holding Sara alongside and pulling her along--but
such are the options on these very stable kayaks. Anyway, with it being
too hot and humid to run, we're taking advantage of Lake Monroe being just 10
minutes from home to put-in, and within minutes from there getting out into the
wilderness where heron are abundant and the bald eagles are so exciting and
magnificent to watch.
During yesterday's few mile lap on the lake, my camera fogged over and quit
(it's very humid), so I gave up on trying to find a way to capture the scene
(the forested hills alongside the lake diminish in the context of the expanse of
the lake and the sky, and it is hard to find a composition that does the
loveliness justice). The moment I stopped focusing on composition, the world
became noisy with cicadas! It was like they'd kept quiet all the time I was
looking at the scenery and the herons with a frame finding view--but of course,
it was just my attention that made it seem that way. In Eldest, Eragon is
under training in the skills of a Rider, and he immerses himself in the
perspective of an ant colony and discovers many tiny details about their life
and society, but his mentor is disappointed, because he could say nothing about
what else was happening in the forest while he so focused on the ants. Eragon is
a dragon rider, and he has the advantage of being more than human. But we, we
have this characteristic that what we are paying attention to, shapes what we
perceive and pay attention to. So, we have to learn to shift our attention from
the detail to the system, to become aware of the context, and the interactions, the
trace between goal, strategy, tactic and outcome and the tradeoffs and balancing
that has to be done. And focus on the detail, where that is architecturally
significant. The key though, is that this is part of the critical "thinking like
an architect" that we have to develop--paying attention to the system, and
system outcomes like system integrity and value from synergy (or collaborations
among the parts, and between the system and other systems and entities in its
context). It is also why the architect role should not be seen and staffed as a
"parachute in/get yanked out after architectural design" kind of thing. Software
systems evolve, and this evolution can be entirely emergent from happenstance,
or guided and reflected on and intentionally shaped. For this last to happen,
there needs to be a role--and a person (or team, in very large projects) in
that role--that is responsible for the architecture. If the architecture is "everyone's
responsibility" then that focus on the the next code drop, the next build, the
next mod to get the current user story working, will dominate attention--and
architecture will subside into inattention. Architecture requires tradeoffs,
tough choices that have to be thought through and advocated. Attention that has
to be wrestled away from the detail, and paid to the system, to systemic forces,
to cross-cutting concerns, to the wash of entropy, to the pull of vested
interests that constantly work their agenda.
And you thought that for once, just for once, I wasn't going to write about
So, how did those Hobie kayaks fit in? Well, compromise and tradeoffs come to
mind. Gosh, family life is very much about compromise and tradeoffs, isn't it? But
I also learn so much I wouldn't otherwise. Like, I'd never have imagined I could
power two kayaks (an extra ~150 pounds, given the weight of the kayak and child) for an hour... I mean -- little me! And that becoming-real-through-being-loved thing, that's cool too!
It is funny how things come together. I referenced Ivan Sutherland's classic
"Technology and Courage"
essay on my "Weaving Ruth" post, and it occurred to me while kayaking with just
my thoughts for company, that Courage is a wonderful treatise on risk. Which
brings me back to the topic I started the month with (finding stories for the
"inspire" part of our "inspire and enable' teaching style for a segment of an
evaluation/improvement/validation customer intervention/workshop, if you must know). I like it when cycles complete so
neatly! [A lot of the essay focuses on academic research, but much applies with
little effort in translation to system development.]
to the 6 Interrogatives
I stumbled on Alex
Matthews blog (he has a description with some pointers to
tree/heat maps). Well, of
course you know we use the 6 interrogatives for organizing access to various
content areas on the Bredemeyer Resources
for Architects site (have done since its inception in '98, though I'm
looking at a site redesign... as soon as I get the book done. Right!) Anyway,
Alex adds "With" to the interrogatives. Nice idea! Of course, "with" should
point to our "Fractal
and Emergent" strategy and tandem architecture paper, should it not? Grin.
Ah, so many opportunities to refer to it. But only one opportunity to be the
first to do so! (Here's
an overview, if you want to provide a "teaser" along with the link to the
7/28/10 Interesting Window on History
7/29/10 Innovation and Creativity
These by way of Anne Merkelson of The Grove (on LinkedIn):
I want to highlight these points from "The
Creativity Crisis" article:
'A recent IBM poll of 1,500 CEOs
identified creativity as the No. 1 “leadership competency” of the
"To be creative requires divergent
thinking (generating many unique ideas) and then convergent thinking
(combining those ideas into the best result)."
"When you try to solve a problem,
you begin by concentrating on obvious facts and familiar solutions, to
see if the answer lies there. This is a mostly left-brain stage of
attack. If the answer doesn’t come, the right and left hemispheres of
the brain activate together. Neural networks on the right side scan
remote memories that could be vaguely relevant. A wide range of distant
information that is normally tuned out becomes available to the left
hemisphere, which searches for unseen patterns, alternative meanings,
and high-level abstractions.
Having glimpsed such a connection, the left brain must quickly lock in
on it before it escapes. The attention system must radically reverse
gears, going from defocused attention to extremely focused attention. In
a flash, the brain pulls together these disparate shreds of thought and
binds them into a new single idea that enters consciousness. This is the
“aha!” moment of insight, often followed by a spark of pleasure as the
brain recognizes the novelty of what it’s come up with.
Now the brain must evaluate the idea it just generated. Is it worth
pursuing? Creativity requires constant shifting, blender pulses of both
divergent thinking and convergent thinking, to combine new information
with old and forgotten ideas. Highly creative people are very good at
marshaling their brains into bilateral mode, and the more creative they
are, the more they dual-activate."
This, from the same article, is interesting:
'In middle childhood, kids
sometimes create paracosms—fantasies of entire alternative worlds. Kids
revisit their paracosms repeatedly, sometimes for months, and even
create languages spoken there. This type of play peaks at age 9 or 10,
and it’s a very strong sign of future creativity. A Michigan State
University study of MacArthur “genius award” winners found a remarkably
high rate of paracosm creation in their childhoods.'
light of this:
breaking confining conception. (Implying nothing about my kids, but
only pointing out how much leveling our society masses against creative and
For Kindred Seekers
confining conception), I find I like it--it might percolate up as
one of my favorite 3, or at least one that is representative. There is
so much in that post that is enormously important to creativity and
architecting and my role in this field, and it is full of eureka-level
convergent insight, playfully written. And, yes, the number of people
that will grok it is certainly limited both by its references (like, who
has seen The Rockae?) and by its style. So?
I expect only extraordinary people to read here--extraordinary, kindred
bliss-following, awe-struck seekers (an adaption of Grady Booch's "awe-struck seeking"
and "follow my bliss" which itself borrows from
Campbell's 'follow your bliss").
"Yet it is important to note that
following one's bliss, as Campbell saw it, isn't merely a matter of
doing whatever you like, and certainly not doing simply as you are told.
It is a matter of identifying that pursuit which you are truly
passionate about and attempting to give yourself absolutely to it. In so
doing, you will find your fullest potential and serve your community to
the greatest possible extent."
Bliss, Joseph Campbell foundation
'Now, I came to this idea of bliss
because in Sanskrit, which is the great spiritual language of the world,
there are three terms that represent the brink, the jumping-off place to
the ocean of transcendence: sat-chit-ananda. The word "Sat" means being.
"Chit" means consciousness. "Ananda" means bliss or rapture. I thought,
"I don't know whether my consciousness is proper consciousness or not; I
don't know whether what I know of my being is my proper being or not;
but I do know where my rapture is. So let me hang on to rapture, and
that will bring me both my consciousness and my being." I think it
-- Joseph Campbell, The Power of
Myth, 1988, (First Anchor Books ed. 1991, p149)
I stumbled on
Scott "Doc" Andersen's blog the other night, and this post is
What or Who is a Visionary.
I will have to write a post on the luminaries that light my
sky--which is, of course, an extension of the "Weaving
Ruth" post, but also with a finer focus. Grady Booch certainly
features prominently among those that light my thinking. Martin Fowler
too--more, the more "human" he allows his projection to become. ;-) But
there are luminaries, and there are influences, and my influences are so
vast and diverse (like Keith Moore, Joe Sventek, Rob Seliger, Dean
Thompson, ...)! And there are people who changed the
trajectory of my life, and to whom I am most grateful (like Martin Griss,
Derek Coleman, and Todd Cotton). Well, lots to think about there!
7/30/10 Architecture Principles
An Architecture Principle is a normative statement that orients (or steers) and
aligns decisions and actions so as to achieve strategic outcomes. That is,
Architecture Principles focus and guide decisions, shaping direction to address
factors critical to achieving strategic intent (or strategic/architecturally
significant system outcomes). Well-stated principles cleave the decision space
between decisions in line with the principle and decisions that run counter to
Rob Seliger introduced us to
architecture principles in the early days (i.e., in the mid '90's) of working on
what would become the Visual Architecting Process. We, like Rob, used the
guidelines described in Paradigm Shift as a starting point, and to avoid
"motherhood and apple pie" principles, we added counterarguments to the
template. There are those, like
Schultz, who argue that architecture principles "are
statements of preferred direction or practice. They reflect a level of consensus
among the various organizations within an enterprise." We
notice that they are statements of direction or practice that we need to
develop consensus and action around, to create focus and align decisions to
achieve strategic intent. For example, we might need to change the status quo to
implement a shift in strategic direction, or to do something consistently that we
have only being doing in isolated instances because it involves hard
choices and tradeoffs. If we are going to take a minimalist approach to
architecture, then we look to the minimum we need to do to ensure that the right
things happen to achieve the strategic outcomes our business seeks.
So we don't want to state general good principles which are good practice but not something we
should extend and encumber the architecture decision set with (everything we add
to the architecture consumes attention of those who create and maintain it,
those who need to understand and act in accordance with it, and those who govern
the question--how long-lived are architecture principles? As business strategy
and architecture drivers change, we want to revisit the set of principles, looking to cull principles that no longer apply, adding principles that reflect the new direction. Once a principle is enculturated within the organization, we may continue to keep it in the
architecture decision set if it is a point of uniqueness to our organization and
we find that as we onboard new developers and architects (new hires or through
acquisitions), the principle is important to helping bring them into our
organization's (technical) culture (for technical principles) with its norms and
principles guiding decisions and practice.
So here's the template we
- principle name: catchy!
- principle statement: clear statement that will guide decisions
addressed by the principle to be in accord with and achieve strategic
significant system outcomes
- rationale: what benefits we get from following the principle
(motivating why we have to change what we do); provides traceability to
strategy or system/architecture objective the principle will help us meet
- counter forces (aka counterarguments or alternatives considered):
provides a place to say we recognize what factors weigh against the principle and what other approaches we
might take (that other people in our environment would argue for) and why
we shouldn't do that. One way to think about the counterargument/counter
force, is that it illuminates implications/things that need to be done to
ensure the principle is followed/viable in the social/business/technical
context. It provides a place to say "in the face of dilemmas and
tradeoffs and pressures we tend to do this, and this is how it
hurts us" and "we could alternatively take this other approach, and this is how that would
- implications: what we have to do to as a result of and to
facilitate following the principle
- scope (optional, as relevant): the intended scope of impact of
the principle (explicitly denoting decision scopes to which the principle
does not apply, so that these don't have to go through the exception request
process, assuming the principle is tended under the governance process).
I broadened counterarguments to counter forces to explicitly direct attention
at any forces (including counterarguments or alternatives that others may try to
use to displace the principle) that may impede our ability to follow the
principle. These will give rise to implications, or things we need to do to
ensure that the principle is technically viable and organizationally feasible.
Other kinds of implications are the downstream consequences of the principle,
issues we will have to take care of, etc.
Responding to a tweeted question about guiding principles for EA, I mentioned
Architecture Principles page
(where examples of principles and other references are collected) on the Bredemeyer site, as well as our
Architects page (you know, describing the Minimalist, With Teeth and
Connect-the-Dots principles). Of course, guiding principles for enterprise
architects are more like the second, and less like the first. The minimalist
principle drives our approach to principles that will be formally collected under the
rubric of the enterprise architecture. What we call these things and how we treat them, is going to have something
to do with whether they are going to be part of our architecture (formally), and
hence under governance. In other words, do teams have to motivate (and even
formally request an exception) their decisions when they run counter to the
principle, or is it something they can treat as simply a guideline? If the
latter, perhaps we'll just call it that -- a guideline.
That said, architecture principles are a
mechanism to express values in terms of behavioral/decision guidance, and are an
important way to shape culture. They are part of the "left hand" work of shaping
and guiding culture so that the architect can use a lighter touch approach (see,
for example, p16 of
The Art of Change: Fractal and Emergent or
here). I suppose there are a few guiding principles for architects contained in that
right hand left hand image, but minimalist says go with the lightest touch
approach that will create the strategic outcome. ;-)
normative – they express how things should or ought to be, how to value them,
which things are good or bad, which decisions or actions are right or wrong. It
might be tempting to overdo our prescriptions here. Every principle we add to
the architecture, consumes cycles -- creating and evolving the principle
statement, understanding and following the principle, and governing the
principle (otherwise they'll be ignored) all costs attention (see
other words, we
can view Architecture Principles as a lever to help set and maintain
direction/course, so long as we don’t get overzealous and wash out their impact
by having so many we overload the attention space and cause them to be ignored.
If, by "architecture principles," we meant
fundamental laws ("facts of nature underlying the working") of software or
enterprise systems, the discussion and guidance would be a lot different!
A guiding principle
is a rule of
behavior that leads to good things; in architecture, we mean a specific approach
that leads to good designs. For example,
statement contains a guiding principle:
integrity can be achieved by uniform application of a limited number of design
Witt, Terry Baker and Everett Merritt.
Software Architecture and Design: Principles, Models and Methods.
p. 9. Van Nostrand Reinhold, 1994
Clearly we are
not saying that architects shouldn't collect, organize, disseminate and
teach guiding principles/approaches
that leads to good designs. The point is only to separate general education of
the development teams from principles that are formally used to shape the
direction and decision space.
I'd love to hear how you think about principles and where you agree or
disagree with what I have proposed as the template and guidelines for its use.
* 1/14/12: I've moved two sentences from within the discussion (where they were
quite buried), and added a third, to the beginning to provide orientation and
placed them in italics. You will notice that this reframing draws on the
discussion of 1/14/12 between Kris Meukens and Ernest Buise on Twitter. (Two
statements were already there, with a word change here or there to sync up with
the third sentence.) Anyway, if I improved on what I had done it is
thanks to Kris and
Ernest, and I think (hope!)
placing an orienting statement at the beginning of the Principles post
makes is more helpful!
Note: Strategy is fractal, so we mean strategy at the level of scope we're
working at -- business strategy for enterprise architecture, product or service
strategy for the related system architecture.
7/31/10 Software Visualization
software visualization community seems to have focused on one meaning of
visualization -- forming images of the design implicit in the code, etc. That
is, there is a focus on the existing system, and making
aspects/characteristics/dimensions of the system visible. So, for example, the
structure of the system is rendered; a picture is formed. I think, however, that
both the following meanings are useful: forming images of system as intended
(imagined, designed) and forming images of the system as it is. Then we have
visualization applied to
design intent ("smoke") and design reflection ("mirrors").
The focus on the (static) code visualization problem, liberated the conception
of software visualization from our standard for visual design expression (the
UML and sysML). This has meant that there has been creative exploration of forms
and metaphors useful for visualizing existing systems. The apparent desire to
distinguish and demark the field of software visualization, with its side-effect
of highlighting weaknesses in design expression/visualization, has this plus
side, but we need to be alert to where one informs and is informed by the other,
because ultimately we would like the evolution of the design expressed in code
and actualized in the system to inform and be informed by the evolution of
design intent. The software evolution we want, is that which is driven because
our intentions evolve, rather than devolution that comes because we have less
and less design traction and start to make more and more ad hoc changes to the
code (to try to keep pace with evolving intent or goals/objectives/needs). If
there is a divergence between the way we express design intent, and the forms
and formats for expression/reflection of the design (structures, mechanisms and
processes) inherent in the code and dynamic system behavior, then we have to
create mechanisms to translate between the two. That's ok too, if we can tool
the translation process, but it is more transparent, there is less to learn,
etc., if the same expressions serve both the design thinking/improving and the
exploration of the design of extant code and running software.
–verb (used without object)
1. to recall or
form mental images or pictures.
–verb (used with
2. to make visual
3. to form a
mental image of.
4. to make
perceptible to the mind or imagination.
or visualisation [www.websters.com]
1. the act or
an instance of visualizing
2. a technique involving focusing on positive mental
images in order to achieve a particular goal
answer a question
- support analysis and reasoning
to explore and discover, encourage
- to look at things in a new way
communicate information to others
- make a point
- tell a story
- part of our cultural heritage
[Card, Schneiderman, MacKinlay, Readings in Information Visualization]
Source: Pat Hanrahan,
How visual models help:
Increase understanding of complex
Explore and compare design alternatives
at a low cost
Form a foundation for implementation
(code generation, reverse engineering and round-trip engineering)
Capture requirements precisely
Communicate decisions unambiguously
(using UML or sysML)
Eclipse Concept: Visual Modeling
Stanford Info Vis Resources
7/31/10 Good Design and Code
Culturally (meaning in our techno-geek culture, not
national/geo-centric cultures), we place emphasis and value on code. So much so,
that we tend to endanger explicit, intentional, documented design. In the heat
of the moment, turning out code rather than explicit design artifacts wins--and
we keep turning up the heat! Even in a "lean" kanban orientation that
includes a requirements/business analysis stage, we have pressure to go from
requirements to code. The kanban process in lean software development might be
called cascades, though this wouldn't be "sexy" in view of the antipathy we've
developed around waterfalls--instead of big drops, these are broken into many
small drops that are repeated as the system is built out in small increments, so
there is more communication between the specialty disciplines of the work
stages as work "flows" between them. These mini-stages and the WIP pull
orientation keep the heat turned up. (Others things too, but the
effect of the heat is what I'm highlighting here.)
Now, I drew on the designer clothing analogy* earlier because it occurred to
me that we need ways to express the value that is in good to great design (where
the measure is in business terms, but including a valuation of structural
integrity). Yes, the design is realized in code, and often the only design
thinking that is happening in a transferable way (taking it outside the head of
the thinker), is happening in the medium of code. Then the question is, are
better designs created simply in the medium of code, or in other media and
mediums (including code, but potentially in targeted prototypes)? And can we
afford to invest in better designs -- indeed, can we afford not to? All the
arguments that are massed along the lines of "we don't know enough" and "we
don't know what we don't know" and so forth, argue for more
experimentation--so long as much of it can be done more cheaply!
So, yeah, sure it becomes a management issue--do we resource experimentation
or do we just resource (fund and staff) building code? After all, until we
have running code the "goodness" of the design is a moot point, and increments
of working code are the best vehicles for testing customer acceptance and
adjusting based on that ultimate of tests, application in the real world. Right?
Well, no. "Best" is context sensitive. If there is high uncertainty about the
value model and/or the design, we can explore options and alternatives quickly
and cheaply using paper mockups (including sketches and models), role play,
performing thought experiments and making reasoned arguments, etc. Given the
uncertainties, risks and challenges we face, design is about getting options on
the table (divergent gathering of alternatives) and combining elements and ideas
to form a convergent approach that will best achieve our desired outcomes
(acknowledging the balance between where we seek to delight and where we will satisfice--recognizing that this too is a design space that we iterate on). So there is
also a leadership issue, and a question of what we choose to advocate, and enculture. Yes, yes, I know all about pushing rocks uphill. And cutting code to
do ad hoc in-situ design is a "letting rocks follow gravity" kind of approach.
If we want to get out from under the rule of the Kludge, to avoid the "big
ball of mud" as dominant design, and create more modular, more evolvable,
persistently mutable systems, we need to design for that--and keep designing for
that!. If we want to create hub architectures that become the platform for
flexible, evolving relationships, we need to design for that. Etc. We design to
achieve desired outcomes, to direct our intellectual and team/community effort
at making the system more the way we want it to be. Which means also deciding
what that is, which is itself a design activity!
Now architecture is about the design of the whole, of the system--the design
of the parts, yes, but so as to achieve the design goals, outcomes, objectives
of the whole; to achieve fit of the system to its context and intended purpose;
and hey, to dynamically, collaboratively find out what that intended purpose is,
even! Architecture is about design across boundaries. The boundaries or joints
within the system. Yes. But also across the boundaries of the system. And design
across the contexts of use. And design to accommodate axes of change we have
high confidence will factor as we evolve the system.
If you are discounting this post as ho hum Ruth at it again, you do us both a
disservice. There are important additions to the common way that architecture is
talked/written about in the above paragraphs--along with the same old drum beat. New
nuances throw light not just on how we articulate and "sell" architecture, but
also have implications for roles and responsibilities. For example, we see that in a fractal approach to system-of-systems design, there
are overlapping roles/responsibilities at boundaries within the system and
across systems, and the system architect
collaborates with, but follows/is led by, the system-of-systems architect. And
so on up and down the scopes of systems.
And we are saying that design has its own payoff in value that is greater for
explicitly, intentionally scouting out value and challenge, articulating
strategies for addressing those, then creating concert among minds to
figure out how to build something better than a purely add and adjust, reactive
kind of approach would produce. The concert among minds part is why we need to
document our designs, and evolve them (intentionally evolve the designs, but
also reflect design decisions made in the code back into the design artifacts).
To ensure design intent, including structural integrity (within the design
envelope we negotiate with those investing in the system), we need to design and
develop a shared conception of the system design--its goals, strategies,
organizing structures and mechanisms.
So, yes, complex systems are that--complex--and complexity tends to be
correlated with big, meaning a lot to grok. This means that visualizations of
the system structure are important, and ways to navigate--to selectively reveal
more detail--are important. That is where much of the work in code
visualization has focused. But we also need to gain intellectual traction so
that we can effectively engage more minds in creating a great system. And we
need to have better ways to figure out where to focus these great minds and the
work they collectively produce---ways to find the value model that will create
differentiating business advantage for our organization.
All of this speaks to the need to design, and to leverage visual design at
that. UML, yes! But informal sketches like Rich Pictures are an important design
tool. We also like The Grove graphic facilitation templates and our derivatives
and spin-offs (like Stakeholder Profiles). And where we are using the UML, at
points we work very sketchily--specifically when we're simply exploring and
probing, covering a lot of lateral ground as we discipline ourselves to think
divergently and get options on the table. But as we converge on a chosen
approach, we use selected UML models along with text to specify key decisions.
Good design enhances the value of the code.
Now. And into the future.
And good design protects the value in the
Now. And into the future.
Because, YAGNI advocates
notwithstanding, today's future slips so quickly into the past, and we have to
be careful what we declare we won't need! It is a judgment call, not an
And good design generally takes considered, collaborative work to produce.
Considered--intentional, explicit, imaginative explorations, reasoning, testing,
probing, trying, advocating and countering, ... Collaborative--drawing on and
drawing in diverse other people with ideas, expertise, perspectives, ...
* I've seen the gap between revenue and assets and market cap used as an
objective valuation of branding, and branding is increasingly related to design,
rather than (only) advertizing spend. Well, I didn't think that is an adequate
picture, but it gives another way of articulating the recognition that design
[Aside: YAGNI arose as a discipline correction (correcting, for
example, our technologist tendency to gold-plate); but overcorrecting is also
Ok, Daniel, do you want to ask me again why I journal? By unraveling that
thought I got to Good design enhances the value of the code. And good design
protects the value in the code. If you configure and reconfigure words,
eventually some combinations fall out that you like! Call it epiphany. Eureka.
Insight. Vanity. Whatever. :-)
I'm teasing myself. But framing is important, and while Dana Bredemeyer and
Grady Booch seem to have an incredible knack for catchy turns of phrase that
orient and inspire action, I have to work at finding them. Dana? Well, how about
"good, right and successful" and "goodwill is the silver bullet"?
I know, what
I landed on sounds an awful lot like "right product, built right"
(which is so commonly used that I have no idea who to ascribe it to). Yet, to get
the design of the product and the design of its guts more right, we have to do more design--where design is the practice of making
things more the way we want them to be (Herbert Simon). That isn't the same as
advocating BDUF, but rather agile architecting that precedes and accompanies
agile development--informing and being informed by iterative and incremental
development. So we embrace a combination of explicit, intentional design, and
implicit, emergent design (in the medium of code) that we reflect on and may
decide to refactor or evolve the design documents to reflect.