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 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 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"
http://en.wikipedia.org/wiki/Architecture

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

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

• Timeline of the European Constitution: http://www.yes-campaign.net/index.php?id=1680

• European Constitution: http://europa.eu.int/constitution/index_en.htm

 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

• 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, "Architecture Mechanisms," The Architect, Vol 4.1, 2001

• Bass, Len, Robert Nord, William Wood, David Zubrow, "Risk Themes Discovered Through Architecture Evaluations," September 2006

• Benjamin A. Lieberman, Analyze use cases by architectural relevance: Using architectural mechanisms to improve the software development life cycle," IBM DeveloperWorks, 23 Jan 2007. (Highly recommended!)

• Lewis, Grace, Lutz Wrage, "Approaches to Constructive Interoperability," Technical Report: CMU/SEI-2004-TR-020, ESC-TR-2004-020, December 2004

• Lewis, Grace, Edwin Morris, Dennis Smith, and Lutz Wrage, "Service-Oriented Architectures as an Interoperability Mechanism," news@sei, 2005

• Skinner, Jim , "Extended Scalability on the Data Tier," Microsoft TechNet, 2007

2/2/07 Architecture Metaphors

• Bio-Networking Architecture Project, Bee colony metaphor, http://netresearch.ics.uci.edu/bionet/

2/2/07 Architecture Case Studies

• Paul Clements and John Bergey, "The U.S. Army’s Common Avionics Architecture System (CAAS) Product Line: A Case Study,"
  Technical Report: CMU/SEI-2005-TR-019, September 2005

• "Microsoft Smarter Retailing Initiative: Enabling the next generation of retail innovation,  Architecture White Paper,"January 2005

• 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, http://www.opengroup.org/onlinepubs/008329799/chap3.htm and http://www.opengroup.org/onlinepubs/008329799/toc.htm

2/2/07 Other Architecture Papers

• Mary Shaw and Paul Clements, The Golden Age of Software Architecture: A Comprehensive Survey, CMU-ISRI-06-101, February 2006

• Platt, Michael, Microsoft Architecture Overview, .NET Architecture Center, July 2002

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

• Boris Lublinsky, "Defining SOA as an architectural style: Align your business model with technology," IBM DeveloperWorks site, 09 Jan 2007

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
http://www.bredemeyer.com/whatis.htm

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 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 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 out—still 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 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 projects—some 31% of projects are cancelled and

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!

2/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 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 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 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 should do
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 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 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/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 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 online business—in 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 way—this 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 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 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 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 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: