I also write at:
Resources for Architects
Architecture Action Guide
Trace In the Sand Blog
HelpMatch Google Group
Trace in the
By Topic (February 2007)
- Most Recent Post
- Vitruvius and Delight
- Bud Not Buddy
- Architecture Mechanisms
- Architecture Metaphors
- Architecture Case Studies
- Something Like HelpMatch
- Context Matters
- Software Architecture
- Web site Referral
- User-Centered Innovation
- Architects and Differentiation
- Opposite of Delight
- Development as
- Communication Diagrams
- Kudos from Warsaw
- Speaking of Scouts
- Fooled by Randomness
- Booch and Email
- Motivating HelpMatch
- UML Modeling
- More Randomness
- Architecture Models
- On Context
from Gerrit Muller
- The Main Thing
- Turing Award
- HelpMatch and Web 2.0
- HelpMatch Urgency
- Last Post
notes... getting old...
You will find a
full year of architect/architecture-related
notes from past months at: January,
In making my notes publicly accessible, I need
to be socially responsible. So, if I inadvertently write something that is
hurtful, inappropriate, in bad taste, and so forth, please
do tell me so I can remedy the problem.
value, fitness and delight
(Daniel's Response to Value and Delight Challenge)
I threw out a challenge for
architects to explain why I think "delight" is architecturally
significant. This challenge was met by exploring what delight means, in
the context of value. This is an architecturally significant avenue to
pursue—we need to be clear what we mean by intangibles like "delight"
in order to sensibly have the discussion. Here are Daniel Stroe's
"... It is always fascinating to study the
etymology of the words -- from
c.1225, delit, from O.Fr. delit, from delitier "please greatly, charm,"
from L. delectare "to allure,
delight," freq. of delicere "entice" (see delicious). Spelled delite
until 16c. when it changed under infl. of light, flight, etc.
c.1300, from O.Fr. delicieus, from L.L. deliciosus "delicious,
delicate," from L. delicia (pl. deliciæ) "a delight," from delicere "to
allure, entice," from de- "away" + lacere "lure, deceive." As a
name of a type of apple, attested from 1903, first grown by Jesse Hiatt
of Iowa, U.S.A. Colloquial shortening delish is attested from 1920."
value: 1303, from
O.Fr. value "worth, value" (13c.), noun use of fem. pp. of valoir "be
worth," from L. valere "be
strong, be well, be of value" (see valiant). The meaning "social
principle" is attested from 1918, supposedly borrowed from the language
of painting. The verb is recorded from 1482. Valuable is attested from
1589. Value judgment (1892) is a loan-translation of Ger. Werturteil.
good: O.E. god
(with a long "o") "having the right
or desirable quality," from P.Gmc. *gothaz
(cf. O.N. goðr, Du. goed, Ger. gut, Goth. goþs), originally
adequate, belonging together," from PIE base *ghedh- "to unite,
be associated, suitable" (cf. O.C.S. godu "pleasing time," Rus. godnyi
"fit, suitable," O.E. gædrian "to gather, to take up together").
Irregular comparatives (better, best) reflect a widespread pattern, cf.
L. bonus, melior, optimus.
First record of good day is from c.1205. Goods "property" first recorded
c.1280, but singular in the same sense was in O.E. The good neighbours
is Scot. euphemism for "the fairies" (1588). Good-for-nothing is from
1711; good-looking is from 1780; good-natured first recorded 1577. Good
sport is from 1917; good to go is attested from 1989.
It would be good if we would have more of
the original text, because each word suffers transformations.
I see delight being the reflection of
good; it is the attraction to good. Let me jump a bit -- it is the love
"Vitruvius' De architectura, good
buildings satisfy three core principles:
Firmness, Commodity, and Delight;
architecture can be said to be a balance and coordination among these
three elements, with none overpowering the others"
Another a bit of etymology:
1410, from M.Fr. commodité "benefit, profit," from L.
commoditatem (nom. commoditas)
"fitness, adaptation," from
commodus (see commode). Commodification first attested 1975, in
reference to art theory.
c.1378, from O.Fr. ferme, from L.
firmus "firm, stable,"
from PIE base *dher(e)- "to hold, support" (cf. Skt. dharmah "custom,
law," Gk. thronos "seat," Lith. dirzmas "strong," Welsh dir "hard,"
Breton dir "steel"). The return in late 1500s to -i- from M.E. ferme was
modeled on the L.
So again what is the link between Genesis, Vitruvius and why was the etymology needed? The good
encompasses equally the value, fitness and delight."
Daniel Stroe, email, 2/1/07
Thank you Daniel! For
starters, I didn't even realize that Vitruvius mentioned delight as one of the three principles of good
architecture. I'd read translations along the lines of:
"firmitas, utilitas, venustas - that is, it must
be strong or durable, useful, and beautiful"
Architectural Foundation: "Vitruvius defined the
qualities of architecture as firmitas, utilitas, venustas. Firmitas, we
might translate as durability. Utilitas is functionality. And venustas
But, on your prompting, I also see:
'It was Vitruvius who first defined the three conditions for good
architecture, "Utilitas, firmitas, venustas" - "Firmness, Commodity and
Delight" i.e. structurally sound, suitability of purpose, and aesthetic
In the Kano model, features
that delight (or excite) are where we differentiate; they are the added
value we provide that distinguishes our product, service and brand from
the competitive playing field. But I take it further. I take delight to
be creating the experience that tips the tipping point because (most)
everyone (in our market segment) is so pleased by the thing they talk
(and write) enthusiastically about it—that the experience turns
even introverts into influencers! And so forth. If we can go
after delight in that sense, then we're there. Our product sells itself!
Though in truth, I think delight is wrapped around the whole customer
experience, so if our customer care is weak, or our quality degrades the
initial experience of delight, or... you get the point... Delight
relates to the whole experience, or at least can be undone by parts of
the experience. Delight can come unraveled if structural soundness or
fit to purpose are not adequate.
I talk about delight because
we architects in the software space so often get caught up in (the
difficulty of achieving) structural soundness and suitability of purpose
that we forget that what we need to be about is delivering all three: firmitas, utilitas,
and venustas, in balance. Yes, the good!
Now, some may argue that this is the turf of
product strategy and requirements, not architecture. I did explore some
ideas along this vein at
but I wasn't going on so much about
delight back then. The general point still holds though. Martin Fowler's
wife is a structural engineer. The way many of us view architecture in
the software world may be more directly analogous to structural
wife thinks (building) "architects are good for the three
B's: bulbs, bushes, birds". Pretty
drawings and aesthetics. Then the structural engineers do the real work
of making sure the building will stand up.
However we cut it, we need to create
architectures that deliver on firmitas, utilitas,
and venustas: structural soundness, fit to purpose, and delight. If the
architect is not involved in identifying the opportunity to create fit
to purpose and delight, we don't get a realistic sense of what it will
take to create structural soundness for that set of features that
address purpose and go beyond, to delight through the experience
(aesthetic and pleasing) that is created. In some organizations,
architects own system definition from system concept to technical
design; in others, they are given the product definition (concept,
strategy and requirements). Others lie somewhere in between. I only get
concerned if architects are not involved in the system concept/strategy
phases, because they see opportunities/challenges others with a
business/market focus/specialization don't see/understand the
technical/risk ramifications of. .../...
Again, thanks Daniel.
For those interested in the
constitution as a metaphor for architecting:
We've been listening to
Bud Not Buddy in the car—it makes going to school fun, but of what
relevance could it possibly be to architects? I already mentioned the
"great maple tree seed of an idea putting down roots that wind their way
into your mind" (not quoting directly, but going from memory). Well, Bud
has all these "Rules and Things to have a Funner Life and Make a Better
Liar out of You" that you might want to compare to "architectural
principles." For example:
Number 3: "If You Got to Tell a Lie, Make
Sure It's Simple and Easy to Remember."
Number 83: "If a Adult Tells You Not to
Worry, and You Weren't Worried Before, You Better Hurry Up and Start
In an exercise related to
the book, the students are told to "make your own list for survival."
Sounds like a good way to position creating architectural principles to
Well, anyway, I highly
the book, and if you listen to it on your commute,
James Avery's reading is wonderful! (The description of the band
starting up is itself music, and the punch-line had the kids in
I wish I'd known Bud's Rules
when I was a kid. They could have saved me a lot of trouble learning
them the hard way. Rule number 3 would have been especially useful! I'm
going to have to highlight this one for my daughter. She begins a lot of
her sentences with "Somewhere I read" or "Some people think" and then
"Ruth's Rules and Things for Spotting a Lie" kicks in and I know it's
going to be a fantastic whopper!
Which reminds me of a little
piece of wisdom James Navarro passed on to me when I started consulting.
I'm paraphrasing partly out of delicacy and partly because I'm going on
a rather distant memory. Anyway, he said, more or less, "Consulting is
easy. When you go in on a client engagement, start sniffing. When you
find the source of the rotten smell, bring it to management's
attention." I've parlayed this into architecture engagements too, and it
works just as well. You see, one becomes accustomed to the smells one
lives with every day, and don't see the obvious. The consultant comes
in, sniffs, and identifies the problem; looks like a hero(ine). But it
was there, all the time. People know about it; they just stopped paying
attention to the smell and overlooked the problem.
Well, I actually don't know
how those things are related... sniffing out lies and sniffing out
bottlenecks and single-points-of-failure... I guess...
"Indeed, every well-structured
software-intensive system is full of
patterns, ranging from idioms that shape the use of a particular
programming language to mechanisms that define the
collaboration among societies of objects, components, and other parts.
At the highest level of abstraction, every system has an architecture,
encompassing the key abstractions and mechanisms that
define that system's structure and behavior as seen from the perspective
of different stakeholders, each with a different set of concerns. In
every case - from idioms to mechanisms to architectures - these patterns
are either intentional or accidental, but insofar as they are visible,
such patterns reflect the style and inner beauty of each system."
Bass, Len, Mark Klein
and Felix Bachmann,
Quality Attribute Design Primitives,"
Technical Report: CMU/SEI-2000-TN-017, December 2000
Bass, Len, Bonnie E.
John, and Jesse Kates, "Achieving
Usability Through Software Architecture," Technical Report:
CMU/SEI-2001-TR-005, ESC-TR-2001-005, March 2001
Bass, Len, Mark Klein,
and Rick Kazman,
Mechanisms," The Architect, Vol 4.1, 2001
Bass, Len, Robert Nord,
William Wood, David Zubrow,
Themes Discovered Through Architecture Evaluations," September
Benjamin A. Lieberman,
Analyze use cases by architectural relevance:
Using architectural mechanisms to
improve the software development life cycle,"
IBM DeveloperWorks, 23 Jan 2007.
to Constructive Interoperability,"
CMU/SEI-2004-TR-020, ESC-TR-2004-020, December 2004
Architectures as an Interoperability Mechanism,"
Paul Clements and John
U.S. Army’s Common Avionics Architecture System (CAAS) Product Line:
A Case Study,"
Technical Report: CMU/SEI-2005-TR-019, September 2005
Enabling the next generation of retail innovation,
Architecture White Paper,"January
Schorr, Oliver, Nobuhiko
Hata, Andrew Bzostek, Rajesh Kumar, Catherina Burghart, Russel H.
Taylor, Ron Kikinis, "Distributed
Modular Computer−Integrated Surgical Robotic Systems: Architecture
for Intelligent Object Distribution," 2000
X/Open Single Sign-on
Service (XSSO) Architecture,
Is Yogi (from the
MIT eCommerce Architecture Program)
something like the community aspect of HelpMatch? I haven't had a
chance to check it out yet, but you can at
This may also be relevant to the notion of sponsored networks:
http://ecitizen.mit.edu/OnlineGatedCommunities/. And, of course,
My daughter said
“You can’t change history." I replied, "No, but you can learn from
history to change the future." (I didn't explain that we may change how
we understand history.) Anyway, it made me
about the importance of our organization's history and drawing on the
and the lessons we have learned. This speaks to architectural
principles as "your own list
for survival," taking into account what you have learned from the past,
and creating strategies for dealing with the same and new challenges as
we shape the future. You might like to take a look at some principles
along that vein, in the
Government of Canada's Federated Architecture.
Now, my son has told my
daughter repeatedly, "You don't know what is going to happen; you only
know what has happened." But a whole lot of what we do is based on our
expectation of what will happen. I was told that part of the Anderson
Consulting interview strategy was to take the interviewee out for a
meal, and privately tell the chef to put a lot of salt on that person's
meal. Then they watched to see if the interviewee tasted the food before
adding salt. Now what does this little test tell you? It tells me that
the person who adds salt before tasting has created heuristics and expectations to speed up common
processes. But it told the Anderson interviewer that the person made
invalid assumptions and acted before testing them out. Ah well, Dana is
reading "Fooled by Randomness" and is enjoying the stories and research
snippets that are woven through it.
Remember, this completes
a whole year of entries.
[2/4/07: Either there's a
lot of shared experience, or some principle leverage going on: see
Draft Enterprise Architecture Principles (2003) versus the
Government of Canada's Federated Architecture (2001) principles.
There's nothing inherently wrong with looking to someone's else
experience when creating principles, but you just have to watch you
don't fall prey to the "shopping cart without a budget" syndrome.
I stumbled upon John
McGregor's paper titled "Context"
and I'm glad I did. In it, John tells this story to illustrate the
importance of context by counterexample:
"On June 4th, 1996, the Ariane-5 launcher
veered off course and exploded within seconds after its flight was
initiated. A detailed report of an independent board of inquiry stated
that the cause of this disastrous failure was due to a software design
error resulting from software reuse [Lions, 96]. The error occurred
because a software component from the Ariane-4 was reused in the
Ariane-5 but the new context varied from the old sufficiently that an
error occurred during execution and caused a failure. The critical
change in context being the difference in the size of the floating point
number representation. The code was not tested extensively because it
had been tested for the Ariane-4 context and had performed as expected."
John McGregor, "Context,"
- Mikko Kontio, Architectural
manifesto: Designing software architectures, Part 4:
Understanding quality attributes, 10 Jan 2005
- Mikko Kontio, Architectural
manifesto: Designing software architectures, Part 3: How to write a
requirements specification, 13 Dec 2004
Frank Kelly has a
blog entry that pulls together various definitions of software
architecture, and his assessment of them. Of the definition on our
Resources for Software Architects
website, he says:
Too many quotes to list so I suggest you click the link. But these guys
are getting very close - they don't just give a blanket single sentence
definition. But the idea of components and their interactions (dynamic
and static aspects) with different views (users, managers, developers
etc.) is pretty darn good. The concept of "decomposability"
is emphasized here.
Also they point out that a "vision" is part of an
architecture also - as an architecture, at least to my mind, is a
growing entity since software is never fully "done". The vision should
encapsulate some aspects of how the architecture will evolve over time.'
art and craft of great software architecture and development blog,
Thanks Frank! Of course, there's also my
What is Software Architecture (5/7/06), and
Modularity and What we can Learn from Trek (6/20/06). Then,
there's the "Software
Architecture: Central Concerns and Key Decisions" paper, and the
definitions area of
the Resources for Software
Architects website. Altogether too much to quote. A reference here
and there might be nice though. ;)
Frank also has a recent
entry (1/29/07) on "Thoughts
on "How do you become a Software Architect?" which sifts the
The Server Side discussion on this topic for entries that resonate
with him. You no doubt remember I tackled the topic "Do
architects need to code?" and I gave Allan Hoffman input for
article on the Software Architect Role—of particular relevance:
my answer to Allan's question
"What advice would you give a young techie who believes he/she would
like to become a software architect?"...
and a host of other entries...
2/4/07 Web Site Referral
This weekend, Ryan searched out his own
choice of domain name, and created his own website:
FloppingFish.Net. Ryan is planning to
watch his site statistics, so do fluff his feathers by paying a visit to
his site! You're "guaranteed" to learn something about fish and
fishing—unless you're a premier ichthyologist yourself, that is!
I've been teaching Ryan some basics of
programming and last weekend he wrote a technical trading system. It told him to buy 59 shares of Boeing stock. He's 8, and no, he
couldn't afford to buy 59 shares, even though he saves diligently, and
even though the
Colts did so well this season! No, it didn't really analyze stock
histories or anything, but hey, it was
a pretty good call!
Scanning around the most recent Harvard Business Review
(February 2007) for something to dig into, my attention was at last
grabbed by Breakthrough ideas for 2007, No. 6: "An Emerging Hotbed of User-Centered Innovation." How's this:
"...recent research shows that 70%-80% of new product development that
fails does so not for lack of advanced technology but because of failure
to understand users needs." And this: "A major auto company recently
presented its 'innovation road map' for the next ten years to a group of
journalists and car enthusiasts... Finally, one listener ... said 'Many
of us have already built and installed every single one of the
innovations you say you are planning to develop in the next ten years.'"
Architects and Differentiation
Companies (primarily) compete on efficiency (cost), innovation, or customer
intimacy. Architecture translates and enables the business strategy,
whether it is allowing higher productivity and efficiency, or more
innovative products in more competitive timeframes, or tailoring the
experience to the customer. A pure cost strategy is a hard play, and over the long-term,
cycles through high organizational pain as cost cutting seems always to come down
to people. In mature markets, there is always cost pressure. Blue
Ocean Strategy looks for new markets—even within old markets.
Innovation through integration of ideas from other domains, invention,
and taking customer innovations, concerns, and values, into our process,
all opens up new ways to compete; new ways to differentiate our products
from the low-cost pack.
We see companies struggling with either/or scenarios—either the
architect is given the responsibility of figuring out how to compete and
the architect feels lost without the market (and marketing) knowledge; or the architect
is left out of the process, which suffers from not including the
architect’s knowledge of technical capability and direction and
[2/8/07 cont.] As our world grows ever more complex, specialists are
needed in more and more areas. But when we spilt apart roles and tasks
in new product or service development, we lose the innovations that
come from the integration of market/customer knowledge and technical
knowledge. When entrepreneurs revolutionize products and even
organizations (MySpace, Ebay, Amazon, and Zappos among them), they have
an advantage—the entrepreneurial/strategic/business savvy is close, in
the same heads even, to the technical savvy. But as the organization
grows, so too does the distance, and the dissonance, among the roles
that form around specialties created to "divide and conquer" complexity.
The architect role has emerged in part to handle technical complexity by
addressing higher level abstractions (fitting more "big rocks in the jar,"
by working with the big rocks before the jar is crowded with little
rocks), and by applying expertise to tough architectural challenges like
creating a consistent, and sound, approach to cross-cutting concerns
like security, availability, performance, leverage across products built
on a common platform (Honda Accord, HP printers, ... medical products,
applications build on an SOA). But the architect role has also emerged
to bring together the islands of marketing/business and
see this being expressed quite clearly in Microsoft's
architect job postings, as well as in their variant of the architect
competency model which underlies what they look for in the MCA.
too, emphasizes the strategic and leadership skills of the enterprise
architect. Of course, for enterprise architecture the demands are all
the greater, since the organizational scope of impact is wider, and so
more must be accomplished through leadership, organizational politics
and strategic sense. Yes, even with the positional power of a CEO, these
attributes are critical. And the enterprise architect often doesn't have
very much positional authority, so relies all the more on personal
effectiveness at leading, inspiring and aligning others to get
architectural approaches rolled out and consistently applied across the
organization. For more on the architect skillset, see:
Architect Competency Framework. Also follow the links from
Architect Role and Skills. Oh yeah, and you could always go back
over the last year of postings in this journal... well, at least you can
say I'm dedicated, even if I've left more of a trail than a trace in the
Opposite of Delight!
Well, when software
"goes wrong" we get wasted time and the total opposite of delight!
Driving in new places, like say, down country roads in England (to find,
say, Dennis Hales), we have
come to rely on those nifty GPS's. So imagine the disgust when the GPS
sent someone I know, round the town of departure on a windy path, then
proudly announced he was at his destination two blocks from where he
in town, and at an address that had nothing in common with the one he
entered! Ok, so this person has a lot of faith in technology and his
ability to use it, being a gadget buff and heavy GPS user. Next try,
dumped out in the countryside, with no roadmap and only a GPS that has
now failed him twice! ... so
it was back to relying on asking for directions. And you know how hard that
is... Actually, in my family, I'm the one that has the harder time
asking for directions, so once again I'm leery of gender stereotypes...
Ok, so I know more
people who have GPS's in England than in the USA, and I know many more people
in the USA than England! There are some factors the slow technology
adoption here; like Cingular charges 10c per text message sent and
received!!! How can a technology take off with that kind of pricing? Who
does better on text pricing? Do tell; being a heavy text messager and
receiver, I'm ready to switch!
Software Development as
things like: "Complex
software is a collective work product, so constructing software systems
necessarily has a social dimension, complicated by the fact that the
work is innovative and non-routine. And we can’t just dispense with
teams: software teams are about two things: getting more expertise so we
can build better products and applications, and getting more bandwidth."
What I forgot to add, is that we're trying to get this collective work
product created by people who work more with computers than other people—and
who like that!
During a recent workshop, one person
remarked on how nice it was to work in a team. Even though we are in
so-called teams all the time, they don't feel like teams, unless we are
putting our heads together to work on a problem; sharing ideas, bouncing
off each others ideas to create better ones. The Visual Architecting
Process builds that shared thinking space, and in so-doing, builds
vibrant teams. It is no accident that the team experience is a highlight
of the workshop—the
team has moved through a systematic process for building alignment, at
the same time as it has moved through a systematic process for building
an architecture the team has confidence in. In strongly aligned teams,
the danger is that the team gets quite vested in its view of the system,
and that is why the validation part of the process is vital to launch
into early and then return to with frequency.
Each piece of the process is important.
At the end of workshops when teams say they now need to meet to decide
what pieces of the process they will choose to do, in their
organization, my heart sinks because they have not realized the
importance of each piece—and unfortunately the pieces that most teams
think they can dispense with are the most key to effective teams!
Perhaps they think management should take care of that! Yet, high
performing, aligned yet highly innovative teams are not the common
experience! And the architecture team is just the start. The
architecture team becomes a team of teams, all of whom need to be
aligned and in high-innovation gear to get the development done on time,
with the properties and capabilities that will delight users.
Ultimately, short-cutting the business of getting a shared sense of what
it is we're all trying to do when we go off and work in wonderful
isolation back at our computers, has a high price. The price is failed
31% of projects are cancelled and
"On the success side, the
average is only 16.2% for software projects that are completed
on-time and on-budget. In the larger companies, the news is even
worse: only 9% of their projects come in on-time and on-budget. And,
even when these projects are completed, many are no more than a mere
shadow of their original specification requirements. Projects
completed by the largest American companies have only approximately
42% of the originally-proposed features and functions. Smaller
companies do much better. A total of 78.4% of their software
projects will get deployed with at least 74.2% of their original
features and functions."
And for failed
projects: "...recent research
shows that 70%-80% of new product development that fails, does so not
for lack of advanced technology but because of failure to understand
users needs." Harvard Business Review
architecture teams to rather work in quick cycles across various
layers of architecture decisions, developing the strategy that addresses
competitive value and architectural challenges, and then strategically
focusing further work on what the architects decide is architecturally
significant. It is not a matter of what we can afford to do, it is
a matter of what we can't afford to miss!
Architecture and the important business of getting it right in our team
"head" and conveyed into the heads of the extended team, falls in this
Booch pointed to
Matt Quail's 2003 post on
complexity. I especially found the lesson Matt draws from
mathematicians pertinent, given the thrust of recent posts: We can
reduce complexity by redefining the problem—at
the source; when expectations around requirements are being raised and
set. This speaks to my on-going concerns around the inclusion of
architects earlier in the process, not just tossing requirements
documents across the role divide at them, fait accompli. I suppose this
is how Matt's thesis relates to
the simplest solution is the best one...??
Anyway, while at
Booch's blog, I popped over to his
take a look at his Turing lecture, and stumbled upon his
complexity. The man is too humble—he
should expose his own work more. I barely happened to stumble on that
complexity slide-set, and I'm happy I did.
Yes, yes... I'm
distracting myself from another round of mutterings about notation changes from UML 1.2 to 2.x (it was supposed to be a standard wasn't it? what's the
point if they keep changing the standard?) necessitating my redrawing
models... Arnon Rotem-Gal-Oz has the
distinction of having tagged TWO women, so I had to see what the
other woman blogs
about. And she has the perfect quote for this:
"Sometimes when I can’t decide what I
I think what would Andy have said
He’d probably say you think too much
That’s ’cause there’s work that you don’t want
"Work" by Lou Reed on
Songs for Drella
Thanks for inviting the girls to play
Arnon. I can assure you, that bears some distinction... Speaking of
letting the girls play along, we're reading
Bridge to Terabithia
at bedtime now (yes, I know what happens). My assistant was asking me
how one gets in to software architecture—she's off to do a PhD in
Psychology in the Fall, but reading our course materials she's
thinking this is a domain she might have chosen, had she known it
existed! And she thinks programming and business school basics are just
essential life skills everyone should learn.
Dana and Sara on
the pond out back,
2/9/07 Why Did this Happen?
So, can anyone
explain why US customs is preventing
KeedoUSA from importing this clothing line designed and manufactured
in South Africa? Of course, it'll give you (ok, me) yet another reason
to stop over in South Africa, but I'm flummoxed and perplexed... I see
the balance of trade is in South Africa's favor, but, but...
How does this relate
to architecture? Economic trends my dear Johnson. If another iron
curtain should be falling, inquiring minds would want to know... I'm
sure there's a reasonable explanation, but it's curtains for KeedoUSA at
least for a while. And did you hear about Avian flu in England (turkeys
near Norwich)? Where is that headed? Less trucks crossing borders in
What is shaping
evolution in your market? What could change? radically? You need to
develop theories about your market. Even if you're off target, thinking
actively about your industry, your markets, your competition, trends and
legislation, will alert you to opportunities and threats. The
environment raises opportunity to differentiate and architectural
challenge, and the environment changes—sometimes
more slowly than you'd expect.
So, how about RFID?
That new technology gestation rate wasn't particularly speeded up by
mandates from power players like the DoD, Wal-Mart and Target. Again,
how does this relate to architecture? It doesn't. Not in the least.
Unless it does. In which case it matters most crucially.
And 56k modems? I
heard someone say they still account for some 40% of the access to their
2007. Who'd have thought?
And sometimes more
architecturally significant depends on your business, and how it is
changing under the forces in the market, the industry, the economies you
and over time.
Communication Diagrams Good For?
Communication Diagrams (or Collaboration Diagrams in UML 1.history) good for,
and do we need them when we have Sequence Diagrams? These are
interaction diagrams, good for exploring the behavior of the system.
Architecture is about creating the structure of the system, but we want
our structure(s) to support the behavior that delivers on system goals.
We can see structure better on the Communication Diagram, by laying out
the components according to the architectural topology (Conceptual
Architecture). Then we can visually explore the collaboration among the
components needed to achieve some goal (a use case step, a mechanism,
etc.). This, for example, allows us to we see interaction across the
Sequence Diagrams are
intuitive (for left-brainers) to create and to read, because we tend to explore behavior
needs to happen, then that... We can create bands of components for the
layers, but the system structure isn't as apparent. So, in one we
primarily see structure, with sequence (shown by Dewey decimal
numbering) requiring more attention to follow. Or we primarily see
sequence (down the diagram), with structure requiring more attention to
Where our tool
supports automated translation from one to the other, we can create
Sequence Diagrams thinking intuitively through the
delegation/collaboration among components, and then use either diagram
depending on whether we are using the model to analyze the structure of
our system or whether we are using the diagram to explain the system
behavior and how things could work (descriptive) or should to work
Ha! Fooled you—you
thought this was going to be one of those influence diagram thingies we
draw to help us strengthen our organizational politics skills, didn't
2/10/07 Visio Templates for UML
http://www.softwarestencils.com/uml/index.html for Visio templates
put together by Pavel Hruby. I knew Pavel back in the Fusion days; back
then (groan, that was more than TEN years ago!!!) he created Visio
templates for Fusion. If you're looking at modeling tools, you might
want to note that Sparx
Enterprise Architect is giving the industry incumbents a run for
their money! The name may be misleading—it
is really a UML modeling tool "at a sensible price." I usually stay away
from mentioning tools because that tends to divide people into "camps,"
but... you might want to look into the
Lattix dependency analysis tool
too. Actually, I think the
Bienfang make good products for architecture modeling. Wall papering
the wall with vinyl to create an all-around-the-room dry-erase white
board is good too.
2/10/07 Kudos from Warsaw
Signing up on the
Resources for Software Architects
mailing list, Aleksander W. from Warsaw, Poland, said:
"Excellent reference site."
sites (wink; you know who I mean), we don't require anyone to sign in,
and signing up on our mailing list (the only place where you can comment
on our site, other than by sending email) is an active but optional step
someone has to take to stay in touch with us—-their
choice, their action. It surprises me daily how many people sign up for
our mailing list. Anyway, just having thousands of architects on the
mailing list is a strong, albeit implicit, compliment and endorsement of
value. Still, it is always rewarding and exciting when someone takes
that extra bit of trouble to say something nice. Even a small phrase,
with "excellent" in it.
Given this general
inertia around giving positive feedback, I took the trouble to shoot
John Wood an email back in November. On Friday (2/9) he replied,
apologizing for the delayed response. Wow! An email from John Wood! Of
course, one day, he'll look back and go "Wow! I got an email from Ruth
Malan!" Yes, he'll remember my email. Ha! I got the standard form-letter
response, but that's not the point. The point is that it doesn't cost a
lot to make someone feel good about what they do. Yet we all tend to
think someone else will do it, so we don't need to. A butterfly flaps
Anyway, if anyone
wants signed copies of
John Wood's book... he can make that happen for you. And please do
tell your personal social network about the book, and
Room to Read. Change the world
through education. John Wood has created an effective avenue to do that;
now we just have to play even a small role, and it will all add up to
change that moves social worlds, makes the amazing possible.
There's the seemingly
small things you do, that can influence another's life, reshape it
fundamentally. And there's recognizing the big things you must do:
every life there are a handful of defining moments, junctures at
which you and you alone define the person you become. So much of
modern literature is an elegy of regret about failing to
recognize these moments or lacking the courage to grasp them.
John Wood did neither."
Geoffrey Moore, author of Crossing the Chasm
Room to Read. HelpMatch.
My moments. My life.
Your moments. Your life.
Of course, I've done some
redefining things in my time, not least of which was co-creating
Bredemeyer Consulting and setting out to serve this wonderfully
creative, innovative architecture community that we all inhabit.
It was a big leap, starting a business to serve a field that was
just birthing itself; yes, next year will mark 10 years for
Bredemeyer Consulting, and it's already been more than 10 years
for our architecture workshops (in their original form).
Now that this Trace in
the Sand has come full circle, I guess I just need to
start reading it from the beginning and I'll save myself some
time writing! I wanted to write on simplicity (having just
written on complexity), but I did that
February last year. I do have some new news though. Dana
bought a neat little book called
The Laws of Simplicity (Maeda, 2006) when he was visiting
the modern art museum and its store in San Francisco a short
while back. Maeda blogs
about it here.
Social Networks: Navigating
There's such an explosion of
everything—information, products; too much to pay attention to
in any dimension. So we rely on guides, to some extent. Kevin's
Architect's Linksblog is a case in point. And thank goodness for
Daniel's pointers to movies (Frank
My Architect, and
Monsieur Ibrahim). Now, I need a "Kevin" or a "Daniel" who I
can trust to scout out music I'll like! Then, of course, there's
Dana, my story scout—yes, my favorite. Dana has been listening
A Sense of the World on NPR.
Sense of the World, a book by Jason Roberts' about a blind
Englishman named James Holman, who traveled throughout the world
in the 1800's without need of assistance. Staying one step ahead
of those desiring to institutionalize or infantilize him for his
blindness, Holman traveled more miles than any other explorer
prior to motorized transportation. Artist, poet, and sportsman,
this extraordinary individual ventured through jungles, across
deserts, and over seas, ever embracing the world, and always
reaching for the "more" that he could become."
for the Blind
The last chapter, read today, introduced
Kish, a blind mobility specialist who is changing the world
for blind people, among other things, teaching them his
technique of echolocation. The story reminds me that whenever I
get discouraged about being a woman in this
software/architecture field, I just need to think about the
prejudice and limiting expectations that shape the world for
blind people and I will remember that I am fortunate indeed!
Yes, we find our way round this world
differently, but that doesn't make our point of view, nor our
2/13/07 Speaking of Scouts
So, at last David Ing has written another classic
Everybody Hates Architects. Thanks Kevin—I'd
stopped looking in on David as he seemed to
"go underground" for a while (no, I don't RSS—if
there was some way to gate feeds based on my workload, that'd be
one thing; but so far, I have to be that gate). Of course, David forgot to mention
all the important things architects do; shield the development
team from the political crud, stuff like that. Which is why
many, many "real" architects don't become "architects"! It has
very little to do with distaste for drawing box and line
thingies; just a lot to do with getting those cowboys so eager
to ride off for a day of work out on the ranch to listen to
where the herd is today, and, worse, convincing those ranch
managers where good grazing is still to be had, and why we have
to go further and further to find it. So, maybe you just have to
jump on your horse and ride along with the team long enough to
get their attention, but really, hanging out with them all day,
everyday day, isn't going to give you any new news on where to
take the herd tomorrow. Or something like that.... maybe I
should have run with the "opening your door on the highway at
90mph" image instead of the horse riding one... ("sat" on a
horse? that's about as good as telling
your dog to "lay"...
there's another book for
Lynn Truss to write, I think!) It's a great post. I'm so
glad to see David stole a bit of time from Taglocity to write
2/13/07 Fooled by Randomness
Dana keeps urging me to read Fooled by
Randomness; lots there for architects, he says (fyi, a
new edition is due out in May). And I need to read Jim's play
(yes, Jim, it's going to be my companion on my trip next week;
no need to get nervous before Monday). But I do have some real
work that needs to get done, and I have a constant eye on
HelpMatch, and what delight will mean for HelpMatch. I was
thinking about our friend,
Madi Hirschland, who is spending the year in Kenya with her
family, practicing the micro-financing that her book is about.
Yes, you guessed it. HelpMatch and microfinance networks. Not a
stretch, I don't think...
you fooled didn't I?!
We're in the
middle of an ice storm, and it's unbelievably noisy outside,
with all the trees groaning in the wind, and branches breaking
with loud cracks under the weight of the ice. Exquisite.
Dangerous. And we don't know how long we'll have power!
I'm working on some slides on risk. Seems
appropriate under the circumstances!
2/13/07 Next Up ... Kudos from Seoul
Signing up on the
Resources for Software Architects
mailing list, C. Lim from Seoul, S. Korea, said:
"Thank you for the
documents which is well organized to read."
Thank you for noticing.
2/14/07 A Study in Complexity
Much of nature's
complexity is hidden, but here time has eroded the cladding, and some of
the structure is revealed.
2/14/07 Happy Valentines Day!
2/14/07 Send Booch an Email Today
I know, I'm mean—but I'm very tempted to email Grady Booch today. You see, I
chuckled at his
Sam-I-am adaptation, and I just know he'd love some nice, warm, fuzzy atta-boy feedback. Wouldn't he? And I love, love, love that he mentioned
Jones. And guess what she's paying attention to? Yes, social
networking! Set my HelpMatch sensors all a-tingling. I should thank him
for that, shouldn't I?
Nah, far be
it from me to rain email on his moment of sunshine. Not even to
call his bluff! For really, does Grady hate email, or hate that
he loves email?
We may do well to remember "It
is the time you have wasted for your rose that makes your rose
I have an email from an architect friend to thank for
reminding me of The Little Prince.
High on the
list of favorite rants in the software field are meetings and
emails. As for me, I love meetings and email; I know... some are
quite set to be a waste of time, but I have to take ownership of
that and recognize I have a role to play in making communication
effective. Even when I can't shift everyone else's attention, I
can shift mine. What I get out of it, is primarily up to me. On
occasion, all I get are some of my best doodles. Mostly, I at
least get new insights. Make connections. Find another point of
view that shatters some blinder I've been wearing.
call my bluff on this. I'm not actually available for any
meetings until, uh, June I think. Then again, I have some FTO due,
so let's see, maybe some time in July?]
couldn't give up email; some of the best debugging of our
website comes via email! Thanks Richard for taking the trouble
to email me. I truly value that. Think of how many hundreds of
people noticed, but didn't take the trouble to say
if I allowed myself to be stressed by the fact that I have 2189
emails in my inbox... Oh my goodness, TWO THOUSAND ONE HUNDRED
AND EIGHTY NINE; get out the defibrillator; my stress level just
shot up! Gasp... I'll just have to go over to the spa and de-tox.
Anyway, Dana really likes
Ryan too! Ryan reminded me of
the cover of this month's Communications of the ACM (spam
and the battle for the inbox). Yes, this is a whole new
world—one where 8-year olds understand spam cartoons and skits!
2/16/07 Along the
"The US government should use
the power of the Internet to engage citizens directly in relief
operations, say two computer scientists. Use of wikis, blogs and
other 'community' tools could help to coordinate responses to
natural or man-made emergencies."
2/17/07 UML Modeling
There is an ongoing discussion
thread on modeling tools going on the
Here's the current state:
1. Borland Together
2. Enterprise Architect
3. Rational Software Modeller
Eion Woods (2/17):
"Good" is a very
personal assessment. Particularly as you don't say what sort of
modeling you want to do. Static structures? Performance?
As others have pointed out, there are fairly good UML tools
about today including Poseidon, Rational Software Architect/Modeller,
Enterprise Architect, MagicDraw and even good old Visio (or
OmniGraffle on Mac).
There are also integrated systems engineering tools like Cradle
from 3SL. And then the really specialist tools like SPE.ED from
Performance Engineering Services.
If you let us know what you're trying to model, perhaps we could
provide more specific ideas.
heard that Poseidon is a good tool for modeling-to-code-
I generally use Visio and these stencils
for UML 2.0:
My opinion is that the modeling process
should drive alignment and facilitate high level communication
and structuring, with specification focused only on specialized
areas of the problem domain. I have worked with other architects
who believe that modeling tools should generate code; I'm not
there, I think modeling tools should generate communication
artifacts to align teams. So, I suppose it depends on your own
perspective on this topic as to what "good tools" mean to you."
"Enterprise Architect is cheaper and UML 2.1 compliant so you can
build profiles for document software architecture views, I am
doing this in this way and its work well."
"IBM RSA (rational system architect) is a good one.
but expensive." [Rational
"I think magicdraw
or Umodel from altova will help you."
Of course, I had
(2/10) my preference for
Bienfang... I tease (myself), but I also appreciate the value of
working with other people on big paper or white boards
And all the talk of tools is so, so important because we need to
put our models in documents and keep them up-to-date; a digital
camera or scanner helps preserve the initial working drafts, but
freezes models in the moment of capture. Still, we
must not get distracted by the tools into not doing the "shared mindspace on paper and white boards thing" first!
Steve is so
very right about what models are good for: communication and
alignment. And we are so much more successful at this when we
don't do alignment to people (like we do to wheels
on a car), but rather work with them in a visual modeling space,
where alignment is an outcome of participation. And models are
good for thinking through the problem, and getting our ideas
expressed so they can reverberate with others ideas, and their
insights and understanding of the problem at hand, so that we
come up with a better, more viable, more exciting, system.
Daniel mentioned they're using
the context of talking about dependency analysis; not as a
visual modeling tool, naturally).
2/17/07 More randomness...
Tracking down Dimitri van Heesch's (doxygen)
acknowledgments, I landed on
Porcupine Tree and was glad of the serendipity of
Deadwing). That struck a Dave Matthews Band "Crash into me"
chord in my memory, so both kept me company for a good while
today! I guess "Glass
Arm Shattering" (also on Porcupine Tree's Deadwing album)
will have me returning to ELO. Time comes to mind, but
that reminds me of other ELO greats from my (sigh) distant past.
And then, that always sends me back to Renaissance, because they
integrate classical, folk and rock influences so exquisitely.
And so it goes. I once described my tastes in music as wanton
(where I meant "having free play", undisciplined/unschooled) to
Dana and he chuckled but didn't disagree... (Context: Dana
knows that my ethics preclude the dissolute meaning of wanton.)
The spread of what I like is rather broad; includes Ann Savoy
and Linda Ronstadt's "Parlez-moi
D'amour." But, I'm indebted to Dimitri for Lazarus! And it
was fun chasing down
Porcupine Tree's influences—notably
Jeff Buckley. His cover of
Hallelujah is simply astonishing. SW of PT says of Buckley:
greatest singer of his generation?"
So, I have to ask, who is the greatest singer of this
Grady Booch (I'm paraphrasing, based
on my take of what he said)
made a point along the lines that
software is different than other engineering because thoughts
are our medium of construction; we compile our thoughts and
we've made something that takes on function. It is one of the
paradoxes, then, of our world, that on the one hand we do
something that is intimately personal, individual, alone
(thinking in a language we can get electronics to co-operate
with), yet we need to work with other people to get more
and more complex, ambitious systems built. That's why we need
architects! That's why we need well-thought out models we can
build confidence in. We use modularity to address complexity,
divide and conquer, simplify through abstractions, hide internal
complexity; and very importantly, we use modularity to create
areas for individual creativity, innovation and experimentation.
Clearly partitioned spaces for thoughts to be poured into forms
that will can be assembled together to deliver function with the
intended properties. Architecture, models—the
vehicles for communication and alignment, to enable independence
and isolation, freedom to experiment, innovate, create, yet
build something bigger, more useful, than any one person could
More than Models
Reacting to my thoughts on
architects creating the context for stronger, more effective
collaboration, Dana reminded me that great architects are great
engineers too. They seek out and address the hard challenges.
Which speaks to the socio-political challenges, but also to the
tough technical challenges, the tradeoffs, the dominant
complexities (a Charlie Alfred term). Some architecture teams
are effective because there is a strong partnership between the
program manager and the lead architect for the program. I
contributed to some research on product development Sara Beckman
was doing at UC Berkeley (some ten years ago, when I was at HP),
and Sara used this image of one body with two heads to express
alignment, and I've been using it since. Walking the same
(aligned) path, but with the bandwidth of two smart heads paying
attention to different dimensions of the teaming challenges of
motivating the best work of many people, and providing the
technical framework within which the best contributions add up
to something that works seamlessly, consistently, to deliver
value. Not just value to the egos of the creators (which, btw, I
see as immensely important), but value to
the users, and all the other stakeholders too.
Breaking into my reverie at brunch,
Dana said "It'll be nice to just watch for a day." "Hmmm," I
replied, hoping the next thing he said would give me an inkling
as to what he was talking about. "A luxury," he said. "What's
that?" I said. "A luxury," he replied. I could see I would have
to fess up and acknowledge I had no idea what he was going on
about. It turned out I hadn't missed anything he said. He just
assumed I'd know what he was talking about. That I'd be able to
sync up with where his thoughts were wandering.
Generally when I hear strategy
roll-out presentations, I get the same feeling that I just tuned
in on something and missed the important lead in that makes it
all make sense. Giving the business team the benefit of the
doubt, I assume that the top business objectives they're so
excited about make a whole lot of sense to them. But without the
context, the competitive landscape and assumptions about how
that will be reshaped over the next few years, it all sort of
sounds pretty much like the top objectives from last year. It
all pretty much sounds like its up to us to make up the real
Context, for context, for context!
Sort of like the "umbrella
diagrams" we use to explain architecture!
2/19/07 Happy New Year!
I was wondering what the Google
piggies were about—yes,
it's the year of the pig. It
didn't show up on my Outlook calendar. Hmm, ... Microsoft!
Update from Gerrit Muller
on additions to the Gaudi Site
(Embedded Systems Architecting)
Here's an update from Gerrit Muller:
The following new
presentations have been added:
"Why Quantified Insight in System Design is Required."
"Reliability of Software Intensive Systems"
The following courses have been added:
Architecting System performance (ASP)
This course has been taught several times now. The readers still
have to be written.
all slides: <http://www.gaudisite.nl/PerformanceallSlides.pdf>
Modeling and Analysis (MA)
This course is being created at this time, the material is still
all slides: <http://www.gaudisite.nl/MA611allSlides.pdf>
book: "System Modeling and Analysis: a Practical Approach"
For PowerPoint users all figures are now also available in
Windows Media Format (.wmf), see <http://www.gaudisite.nl/PictorialIndex.html>
See for other recent changes:
2/26/07 The Main Thing
"The main thing is
to keep the main thing the main thing."
This is a great quote to help guide
our focus. I wonder how many would be as excited about it, if
they knew it is a quote from Stephen Covey, the author of The
7 Habits of Highly Effective People (given that Covey is
type-cast as a management guru). One of Covey's habits
with the end in mind."
Daniel Stroe mentioned the Phillips Academy motto:
"Finis origine pendet: The
end depends on the beginning."
Begin with vision; begin with the
right stuff (capability and focus); find the main thing, and
keep it in focus.
Daniel (you'll recall—my movie
scout) recommended The Emperor's Club; I haven't seen it
yet but reading the synopsis it sounds like a good movie for
architects (so I get to write off the purchase as a business
expense?); at least for those architects who are sensitive to
our role as shapers of opportunity, hence of lives.
2/26/07 ACM Newsgram:
Award Honors Frances Allen
Emerita Frances Allen became the first female to receive the
prestigious ACM A.M. Turing Award for her pioneering work in the
"theory and practice of optimizing compiler techniques." In the
1970s Allen helped promote higher-level languages over machine
languages and was responsible for ways to improve compilers so
programs could run on different machines. "She's really the
mother of customer-oriented computing," says IBM VP Robert
Morris. "She was an early proponent and practitioner of what has
become our innovation model. There was a time when we thought of
innovation as being just associated with invention. Now we see
it as a path from the invention through to where it has an
impact on how people live their lives." Allen sees the
award as a way to further her efforts to bring more women into
computing. She says, "I have worked hard for women to be
recognized, and I'll use this as a platform to get more
attention to the role of woman in computing." One of
ACM's goals is to get more women interested in computer science,
as only 26 percent of U.S. IT workers are female, down from 33
percent in 1990, and only 15 percent of undergraduate CS degrees
from major universities go to women. "It's essential for women
to participate," says Allen. "A diversity of people can bring a
much more creative environment and better results." For more
information on the ACM A.M. Turing Award, see
years of Turing Awards, and Frances Allen is the first
woman...??? If even only 1 in 10 people in computer science are
women, the law of averages says something beyond sheer odds is
stacked against women here. Now, let's see, it’s
not like Frances Allen made her contribution to computer science
yesterday!!! I don’t suppose it was an “affirmative action”
award do you?
When one woman architect heard there
would be 3 of us women at a workshop, she said: "Great! But I
won't know how to act!" I often feel the opposite; being small
of frame and voice, it is hard for me to be as forceful as a
given situation may require. Fortunately, a "come-from-behind"
win on the credibility front is generally good enough, as I find
it awfully hard to "command" respect and "tell" people what to
do. My 7-year old daughter is a little czar; she has power
figured out, and uses it. Instinctively, we try to rub that edge
off her, but it also surfaces truly mixed feelings for me. One
position is "I've worked with women like that, and it's not
good." The other position is "wouldn't she be better prepared to
work in contexts that are shared with men, if she gets to grow
her alpha female tendencies?"
When my kids were toddlers, I
observed that we parents are responsible for facilitating an
emergent human being through a vastly speeded-up evolution, from
early human, through (at least hours of sheer) barbarism, to a
"civilized," "developed," "educated" modern person. So, we're at
an important juncture, where our values tell us not to
discriminate based on gender (and other differences), yet nature
does clearly discriminate (how many new fathers out there would
like to have those hormones that make the nursing mother so
unstressed??), and our social norms discriminate, often in
hidden, not well-understood ways. And all this makes it hard,
parenting the next generation "modern woman"—and man—in the
current generation of expectation and norm. Getting more women
interested in computer science is a complex issue. I'm glad that
Frances Allen is using the Turing Award podium to raise
awareness, for awareness has to be where it starts.
Along the way, it may be good to
highlight innovation, systems thinking, communication, and
design for customer-orientation as subject areas that complement
programming courses in software engineering curricula. I believe
this would interest more young women and men, persuading
them to enter the field, and better prepare them for a
successful role in it.
2/26/07 MIT Sloan Management
MIT acted with great foresight in
making course slides freely available on their website (MITOpenCourseware)—recognizing
that course value is greater than the slidesets and readings.
Nevertheless, I've enjoyed looking through what top business
schools are teaching these days, and you might like to take a
Quite a number of "accommodations"
we have made to existing products because they didn't quite meet
a need, are now products on the market. And this is happening in
household after household, and business after business. Yet
architects push back when I tell them they have to really get
face time with their customers/users. In many cases, it doesn't
have to be funded in a big way; you can get creative—find a
local community group (the local Harley club), spouse of a
colleague, etc. and work the network from there. As soon as
you've found some "delight" factors (innate but unmet needs),
you'll be able to motivate more attention to this area of
innovation through the conjunction of technology, end user
innovation/creativity, and unsatisfied needs.
How many of you routinely do patent
searches? From time to time I'll do a patent search related to
some architecture project—a heritage from HP Labs. But
last week as I was thinking about patents again, and I decided
to explore around and see how many of the architects I've worked
with have registered patents. Not very many. Then I looked up an
number of visible companies on
and was surprised at the number who have few, if any, patents
registered. So, it appears these companies do not view
themselves as innovators, or don't encourage their architects
and inventors to think along the lines of protecting their
innovations. It is interesting that the "usual suspects" in
technology leadership—the likes of Wal-Mart and
Hewlett-Packard—have a strong patent history. I'm not going to
mention who I found that doesn't. Now, this doesn't necessarily
tell us much. Some fields are moving towards "open source" and
others may simply not want to bear the legal costs of
registering, and more importantly, protecting patents. But, as
our strategic sensibilities are raised, we clearly need to
consider patents in our exploration of opportunity and threat in
the competitive landscape. If you haven't been paying attention
to patents, you might also be surprised to find a mine of
architectural information buried in the invention descriptions.
[3/27/07: And see Grady Booch's
Patents gone Wild post from 3/19/07. ]
HelpMatch and Web 2.0
Since I have characterized HelpMatch
as clearly Web 2.0, and notions of Web 2.0 are firming up, I
thought I'd surf around and make sure my intuition was right on
the money. So, first off, we have O'Reilly's landmark article "What
is Web 2.0: Design Patterns and Business models for the Next
Generation of Software." I like the Web 2.0 "Meme Map" on the
1st page of the article. Here are some highlights from the
article that I see as particularly pertinent to HelpMatch:
is a truism that the greatest internet success stories don't
advertise their products. Their adoption is driven by 'viral
marketing'—that is, recommendations propagating directly from
one user to another. You can almost make the case that if a site
or product relies on advertising to get the word out, it isn't
"eBay's product is the collective
activity of all its users; like the web itself, eBay grows
organically in response to user activity, and the company's role
is as an enabler of a context in which that user activity can
happen. What's more, eBay's competitive advantage comes almost
entirely from the critical mass of buyers and sellers, which
makes any new entrant offering similar services significantly
what we believe to be the core competencies of Web 2.0
packaged software, with cost-effective scalability
unique, hard-to-recreate data sources that get richer as
more people use them
long tail through customer self-service
the level of a single device
user interfaces, development models, AND business models"
is Web 2.0," by Tim O'Reilly, O'Reilly 9/30/2005
HelpMatch, as a social networking
space focused on providing help to those in chronic or acute
need, has a window of opportunity that will close as other kinds
of solutions are put to the market survival test. If we
architects want a great big sandbox of an application, one that
can truly make a difference in the world, then we need to seize
the day (carpe diem)!
I have registered HelpMatch.org for
the HelpMatch help network, and HelpMatch.net for use by the
technical community forum as we architect and build HelpMatch. I
would like to very shortly have HelpMatch.net launched with
community conversation tools like a blog, wiki, etc. So, areas
I'd like immediate help in are:
recommending a wiki engine for
HelpMatch.net (what does wikipedia use?) and blog tool (I'd
default to WordPress; other recommendations/considerations?)
recommending a hosting service
for HelpMatch.net, recognizing the need to start low cost
and potentially/hopefully to scale quickly
provide vision input, and vision
tell me what I'm forgetting!
We need to get the vision statement
pounded into shape quickly, so that we can form a Board of
Directors and get HelpMatch formally launched as a non-profit
organization that can take donations to get infrastructure in
place. In addition to the Board of Directors, I would like to
form an Architecture Leadership Council, and hold an "indaba"
n. A council or meeting of indigenous peoples
to discuss an important matter.)
Again, we need the vision in place
to do this. I'm hoping the Indy Architects Group will give some
face-to-face time to this. Of notable mention—Al de Castro and
Barry Crist, as the two primary/consistent sources of
inspiration for HelpMatch ideas, and also
Jeff Price, Gene Shin, and Kurt
Kirkham. We also have new members who are just joining.
As soon as we get some
collaborations infrastructure in place, we'll all have to start
serious viral networking to create the space where our technical
viral networking habits can translate into serious goodness for
humanity—personal, individualized yet massive scale help! What
Oh, and if you have contacts with
philanthropists who'd like to help people help each
other, please put me in touch with them. I'm going to be
rattling my network, but this is an opportunity you can offer
and there is no time like the beginning to make a difference!
While it will be good to have people involved on the HelpMatch
organization side who are committed to putting real time into
this, money will also help speed this engine for social change
up the network effects curve!
You can stand on the sidelines and
observe, and be part of the damping force of disbelief. Or you
can pitch in and make this happen. You have the power to make
this technology's biggest contribution to the plight of poverty
and disaster, chronic and acute need, at the individual, family,
community, organization and national level! Each person who
reads this and does not do something active to contribute,
shares responsibility for inertial drag. You are the first link
in the chain reaction that will spread HelpMatch around the
world. Each person who acts, shares responsibility for beginning
the network process that this needs to reach its potential. Your
involvement will give you the satisfaction of seeing this
through its crucial beginnings, setting in process the
technology hub that will link people to people committed to
making a difference.
You can start to connect the flow of
influence by linking to
Very soon we'll have the HelpMatch
portal up and running, but in the meantime, why hold back? If
you have something against my facilitating getting this ball
rolling, let's talk about that. If not, link! Or, alternatively,
create your own statement (and tell me where it is, so I can
point others to it)! The least you will
get is embarrassing me if I idle instead of playing a role in getting this into
high gear! But the time is now! This is our defining moment!
Daunting: The most serious mistakes are made on the first day.
The end depends on the beginning.
Exciting: Begin with the end in mind. The end, my friends, is
the obvious place to turn to give and receive individual help:
to connect directly or through people and groups we trust to
those we can directly help. The technology is ready for this. It
just takes some leadership, initiative, and yes, hard work with
a hammer (you have to read a
previous post or just go right to
Bono's commencement address). We are the architects of a
HelpMatch Core Values
Here's a first cut at a core value for HelpMatch:
As soon as we have the wiki going, you can directly edit stuff
like this; until then, just
email me your
additions, changes and suggestions. Having me at the hub of
edits at this point goes against the grain of the core values,
but it is just temporary. I'd rather do this than wait longer to
EA and SOA Webinar
If you want to rave about my journal, I can be reached using the
obvious traceinthesand.com handle. If you want to rant, its
email@example.com. Just kidding,
welcome input, discussion and feedback on any of the topics in this
Trace in The Sand Journal,
my blog, and
the Resources for Architects
website, or, for that matter, anything relevant to
architects, architecting and architecture! I commit to using what you
teach me, to convey it as best I can, help your lessons reach as far as
I can spread them. I try to do this ethically, giving you credit
whenever I can, but protecting confidentiality as a first priority.
Referencing journal entries: I figure at some point, someone,
somewhere, is going to find something I've written worth linking to. I
know, it's a long shot. But hey, it's a world full of different people,
and if I write long enough, someone is going to
stumbleUpon this Trace in
the Sand and be
delighted enough to want to tell someone else about it.
So, here's how: To link to a particular entry, I bookmark and
link to section titles from the sidebar, so you can copy the shortcut
(from the sidebar).
Restrictions on Use: All
original material (writing, photos, sketches) created by Ruth Malan on
this page is copyrighted by Ruth Malan. All other material is clearly quoted and ascribed to its
source. If you wish to quote or paraphrase fragments of material
copyrighted by Ruth Malan in another publication or web site, please
properly acknowledge Ruth Malan as the source, with appropriate
reference to this web page. If you wish to republish any of Ruth Malan's
or Bredemeyer Consulting's work, in any medium, you must get written
permission from the lead author. Also, any commercial use must be
authorized in writing by Ruth Malan or Bredemeyer Consulting. Thank you.