A Trace in the Sand
Online Architecture Journal
by Ruth Malan

I also write at:

- Resources for Architects

- Architecture Action Guide

- Trace In the Sand Blog


- HelpMatch Wiki

- HelpMatch Google Group


Other Interests

Trace in the Sand
Architecture Journal

     February 2007
Su Mo Tu We Th Fr Sa
                          1   2   3
  4    5   6   7    8   9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28



- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- Current


- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December


- January

- February
- March

- April

- May

- June

- July

- August

- September

- October

- November
- December

- January
- February
- March
- April

- May
- June
- July
- October
- December


- February
- March
- April
- May
- June
- July
- August

- September
- October
- November

- December

- March

- April
- May
- June
- July
- August
- September

- October
- November
- December

By Topic (February 2007)
- Most Recent Post
- Vitruvius and Delight

- Constitution Metaphor
- Bud Not Buddy
- Architecture Mechanisms
- Architecture Metaphors
- Architecture Case Studies
- Something Like HelpMatch
- History
- Context Matters
- Software Architecture Definition
- Web site Referral
- User-Centered Innovation
- Architects and Differentiation
- Opposite of Delight
- Development as Communal Endeavor
- Complexity

- Communication Diagrams
- Kudos from Warsaw
- Speaking of Scouts
- Fooled by Randomness
- Booch and Email
- Motivating HelpMatch
- UML Modeling
- More Randomness
- Architecture Models
- On Context

- Update from Gerrit Muller
- The Main Thing
- Turing Award
- Patents
- HelpMatch and Web 2.0
- HelpMatch Urgency

- Last Post


Architecture documentFebruary 2007

2/1/07 Architecture notes... getting old... 

You will find a full year of architect/architecture-related notes from past months at: January, December, November, October, September, August, July, June, May, April, March, February.

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.

2/1/07 Architecture: 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 pursuewe need to be clear what we mean by intangibles like "delight" in order to sensibly have the discussion. Here are Daniel Stroe's reflections:

"... It is always fascinating to study the etymology of the words -- from http://etymonline.com:

delight: 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.

delicious: 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 "fit, 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 of good.

"Vitruvius' De architectura, good buildings satisfy three core principles: Firmness, Commodity, and Delight[2]; architecture can be said to be a balance and coordination among these three elements, with none overpowering the others"

Another a bit of etymology:

commodity: 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.

Firmness: 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:

  • wikipedia: "firmitas, utilitas, venustas - that is, it must be strong or durable, useful, and beautiful"

  • American Architectural Foundation: "Vitruvius defined the qualities of architecture as firmitas, utilitas, venustas. Firmitas, we might translate as durability. Utilitas is functionality. And venustas is beauty."

But, on your prompting, I also see:

http://www.trp.dundee.ac.uk/research/glossary/vitruviu.html): '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 pleasure.'

Delight differentiatesIn 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 http://www.bredemeyer.com/ArchitectingProcess/ArchitecturalRequirements.htm, 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 engineering. Martin's 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.

2/1/07 Constitution Metaphor

For those interested in the constitution as a metaphor for architecting:

 2/1/07 Bud not Buddy

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 'Cause You're Already Running Late."

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 me!

Well, anyway, I highly recommend 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 stitches!)

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...

Who knows...

2/2/07 Architecture Mechanisms

"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."

Grady Booch, Architecture Handbook website

2/2/07 Architecture Metaphors

2/2/07 Architecture Case Studies

2/2/07 Other Architecture Papers

2/2/07 Something Like HelpMatch

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 http://www.onlineyogi.com/. This may also be relevant to the notion of sponsored networks: http://ecitizen.mit.edu/OnlineGatedCommunities/. And, of course, there's Microsoft's Community Server...

2/2/07 History

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 think again about the importance of our organization's history and drawing on the experiences 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 Tasmanian Government's 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. Each principle costs.]

2/3/07 Context Matters

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," Jot.fm, 9/2005

2/3/07 Architectural Style

2/3/07 Architecture Qualities

  • 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

2/3/07 Software Architecture Definition

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:

'3) Bredemeyer Consulting

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.'

Frank Kelly, art and craft of great software architecture and development blog, 1/6/07

Thanks Frank! Of course, there's also my blog entries: 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 his monster.com 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!

2/4/07 User-Centered Innovation

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.'"

2/7/07 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 marketseven 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 innovative thinking.

[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 technology/development.

We 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. GEAO 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 sand!

2/8/07 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 started outstill 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!

2/8/07 Software Development as Communal Endeavor

I say/write 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 peopleand 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 workshopthe 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. Visual Architecting Process

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 projectssome 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."

IT Cortex, http://www.it-cortex.com/Stat_Failure_Rate.htm

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 (February 2007).

I encourage 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 category!

Complexity2/9/07 Complexity

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 problemat 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 Occam's Razor: the simplest solution is the best one...??

Anyway, while at Booch's blog, I popped over to his link to take a look at his Turing lecture, and stumbled upon his presentation on complexity. The man is too humblehe 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 should do
I think what would Andy have said
He’d probably say you think too much

Skaing on the pond out backThat’s ’cause there’s work that you don’t want to do"

"Work" by Lou Reed on Songs for Drella


Thanks for inviting the girls to play too, 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 architectureshe'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/11/07

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 Europe?

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 changessometimes 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 online businessin 2007. Who'd have thought?

And sometimes more quickly. Take MySpace!

What is architecturally significant depends on your business, and how it is changing under the forces in the market, the industry, the economies you compete in—now, and over time.

2/10/07 What are Communication Diagrams Good For?

What are 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 layers.

Sequence Diagrams are intuitive (for left-brainers) to create and to read, because we tend to explore behavior that waythis 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 seek out.

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 (prescriptive).

Ha! Fooled youyou thought this was going to be one of those influence diagram thingies we draw to help us strengthen our organizational politics skills, didn't you???

2/10/07 Visio Templates for UML 2.0

See 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 misleadingit 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 likes of 3M and 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."

Unlike some 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 its wings...

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:

"In 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).

2/11/07 Simplify, Simplify, Simplify

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 in 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.

2/12/07 Real-time

Reentrancy: http://www.ganssle.com/articles/areentra.htm

2/12/07 Social Networks: Navigating Information Explosion

There's such an explosion of everythinginformation, 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 Gehry, 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 scoutyes, my favorite. Dana has been listening to A Sense of the World on NPR.

"A 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.World Access for the Blind

The last chapter, read today, introduced Dan 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 contribution, irrelevant!

2/13/07 Speaking of Scouts

So, at last David Ing has written another classic post: Everybody Hates Architects. Thanks KevinI'd stopped looking in on David as he seemed to "go underground" for a while (no, I don't RSSif 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 it.

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...

Randomness. Had you fooled didn't I?!

2/13/07 Ice Storm

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."

Complexity exposed by weatheringThank 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.

A metaphor.

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 Carol 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 so important." 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.

[But don't 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?]

And I 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 anything... shudder.

Then again, 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.

or not...

Anyway, Dana really likes Grady's Sam-I-am adaptation! 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 worldone where 8-year olds understand spam cartoons and skits!

2/16/07 Along the Lines of HelpMatch

"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." http://www.nature.com/news/2007/070212/full/070212-12.html

2/17/07 UML Modeling

There is an ongoing discussion thread on modeling tools going on the Visual Architecting Google Group.

Here's the current state:

"Techlogix" (2/21):

"My subjective rankings

1. Borland Together
2. Enterprise Architect
3. Rational Software Modeller
4. Poseidon
5. ArgoUML"

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? Concurrency?

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.

Steve (2/17):

"I have heard that Poseidon is a good tool for modeling-to-code- generation (http://www.gentleware.com/products.html).

I generally use Visio and these stencils for UML 2.0: http://www.softwarestencils.com/uml/index.html

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."

Adrián (2/16):

"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." [Sparx Enterprise Architect]

Richard (2/15):

"IBM RSA (rational system architect) is a good one. but expensive." [Rational Software Architect]

Hari (2/15):

"I think magicdraw or Umodel from altova will help you." [MagicDraw] [Umodel]

Of course, I had already mentioned (2/10) my preference for 3M and Bienfang... I tease (myself), but I also appreciate the value of working with other people on big paper or white boards informallyfirst. 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 doxygen (in 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 discovering "Lazarus" (on 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 influencesnotably Jeff Buckley. His cover of Hallelujah is simply astonishing. SW of PT says of Buckley: "The greatest singer of his generation?" So, I have to ask, who is the greatest singer of this generation?

2/17/07 Architecture Models

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. IComponents shield areas of uncertainty and experimentt 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, modelsthe 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 build.

2/18/07 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. 

2/18/07 On Context

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 strategy, again.

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!

2/24/07 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."
presentation: <http://www.gaudisite.nl/QuantifiedSystemDesignSlides.pdf>

"Reliability of Software Intensive Systems"
presentation: <http://www.gaudisite.nl/ReliabilityOfSoftwareIntensiveSystemsSlides.pdf>

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.
page: <http://www.gaudisite.nl/EA.html>
all slides: <http://www.gaudisite.nl/PerformanceallSlides.pdf>

Modeling and Analysis (MA)
This course is being created at this time, the material is still highly preliminary.
page: <http://www.gaudisite.nl/MA.html>
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 is "Begin 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 recallmy 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: The Turing Award Honors Frances Allen

"IBM Fellow 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 http://campus.acm.org/public/pressroom/press_releases/2_2007/turing2006.cfm"

BusinessWeek (02/23/07) Hamm, Steve

40 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 Strategy Slides

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 look at:

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 creativefind 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.  

2/26/07 Patents—Definitely Architecturally Significant!

How many of you routinely do patent searches? From time to time I'll do a patent search related to some architecture projecta 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 FreePatentsOnline, 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 leadershipthe likes of Wal-Mart and Hewlett-Packardhave 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. ]

2/27/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:

 "It 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 Web 2.0."

"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 less attractive."

"... summarizing what we believe to be the core competencies of Web 2.0 companies:

  • Services, not packaged software, with cost-effective scalability

  • Control over unique, hard-to-recreate data sources that get richer as more people use them

  • Trusting users as co-developers

  • Harnessing collective intelligence

  • Leveraging the long tail through customer self-service

  • Software above the level of a single device

  • Lightweight user interfaces, development models, AND business models"

"What is Web 2.0," by Tim O'Reilly, O'Reilly 9/30/2005

2/28/07 HelpMatch Urgency

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 review

  • 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" pretty soon. (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 a vision!

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 better future.

2/28/07 HelpMatch Core Values

Here's a first cut at a core value for HelpMatch:

  • By the people for the people: HelpMatch will be created and run by the open community of volunteers, with the goal of serving people in need

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 "get going"!

2/28/07 EA and SOA Webinar


Feedback: If you want to rave about my journal, I can be reached using the obvious traceinthesand.com handle. If you want to rant, its ruth@traceinthesand.ru.cz. Just kidding, I 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.

Copyright © 2007 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: February 1, 2007
Last Modified: February 28, 2007