I stumbled upon a neat example in the building architecture space where the architects shifted the requirements (literally) and also where the construction began in the midst of the design work. And what did the architects achieve? Boosting the bottom line and better integration of people-oriented spaces.

10/2/09 An Eye for an Eye Makes the World World Blind

Mohandas Gandhi was born October 2, 1869. What a good thing, that was! For South Africa (Gandhi influenced Nelson Mandela) and the US (he influenced Martin Luther King). When Cara Dillon sang ♫There Were Roses♫ last Saturday night, I thought of how we still do that eye for an eye thing, and how remarkable is was that Gandhi used peace and love as the lever that moved his world, and my world, and our world. (At the end of the song she invited the audience to join in the chorus. Obviously Dana was closest to me, so I have a video of Dana singing harmony with Cara Dillon, which is neat.)   

10/2/09 Telling Visuals!

• August may have been cool in the US interior, but globally it was one of the warmest on record--see the visualization on NOAA!
• Swine flu latest: visualized!

and for fun:

• Christoph Niemann's I confess (don't worry, it's nothing like David Letterman)

but then, no-one appears to have told Christoph about my solution to the "sleep: it's actually complicated" thing...

10/3/09 Collective Memory and Visualization After Design is Built

Another post from the building architecture space raises an interesting thought for us, relative to "architecture mining." It has to do with harvesting the collective memory of the development organization to build up a richer (set of) model(s) of the system than static and dynamic analysis tools alone could do.

It is interesting that digital preservation is being considered for buildings and even cities, which parallels Grady Booch's mission to preserve code for landmark software systems. Thank goodness he saw that need, and has thrown his passion and leadership into it, for he's right--time has already washed away the code traces of important genre launching and genre defining systems, and we need to act to identify and save these stand-out pieces of our collective history.      

10/3/09 Gestalt Principles

Looking at the Gestalt Principles for visual perception, I was wondering if we were to draw out the "Gestalt" (unified whole) principles for architectural design, what would they be? In other words, what contributes to system integrity? We can simplify that somewhat, and ask what principles help achieve structural integrity? The "Booch fundamentals."  What else?

Eb Rechtin said: "The essence of systems is relationships, interfaces, form, fit and function. The essence of architecting is structuring, simplification, compromise and balance."

Hmm, would Grady accept Compromise into the set, do you think? Then SCARS would have a principle for each letter. That's sort of backing into it, but serendipity can be quite inventive. Nah. Tradeoffs would be better, and then you get STARS! (What Darth-Don sees.) However one words it, I guess I'm saying that we need, in the set of fundamentals, something to do with finding the integrative solution that balances interacting and even conflicting cross-cutting concerns.

Now I am going to have to go digging around in the work of the other architecture and systems thinking giants too, and see if there is something more there to distill into a minimalist but satisfying set. First, I suppose I'd be swimming against the flow, since many define system integrity to be what I think of as structural integrity (e.g., not brittle both from a failure and a modifiability standpoint). But I don't stand on ceremony just for the sake it. And I think how we define system integrity should be informed by systems thinking. For example, system integrity should explicitly address fit to context and to purpose as well as the "as if of one mind" characteristics like consistency and harmony. I went after the integrity point back in January (delight and excellence), and need to revisit it.

Out hiking today, I told Ryan about the Wright brothers using the strategy of switching sides in their arguments. Dana added "I can see that--they were determined to find a solution! When you work on a lot of problems, you learn that means you fail a lot. Arguing the other's position is a great way to discover the weaknesses and strengths of an approach." Or something like that. I'm paraphrasing. From memory. We were hiking, remember. In the woods. With the dog. And it was lovely--wind blowing through the trees just hard enough to be full of sound, but not so hard as to stir caution in me.

How does that relate to Gestalt? Well, yin and yang, I suppose. Complementary opposites that help us understand the whole.

10/3/09 Systems References

• Dori, D. Object-Process Methodology: A Holistic Systems Paradigm. Springer Verlag, Heidelberg, New York, 2002.

• Friedenthal, S., Moore, A., and Steiner, R. A Practical Guide to SysML: The Systems Modeling Language. Morgan Kaufmann, 2008.

10/3/09 Just knick-knacks

Some little stories buried in these, that might come in handy some time...

• 15 companies that originally sold something else
• 10 technologies we stole from the animal kingdom

10/3/09 Less is More

That being the case, I scrapped most of this entry. :-)

A word about Kolya: to sum it up, I suppose I'd say it is about how we think we're nurturing our children, but they're really growing us!   

10/4/09 Boundary Conditions and Interfaces

 I just had to add, there's nothing quite like working (or "working") at your computer with a 9 or 11 year old in your lap! It makes it hard to catch up on xkcd! I hadn't even finished reading this one, when Ryan said "It doesn't work if you're under 14." Ryan's immediate test of xkcd's dating rule, and his instinct to then find just where it falls down, is certainly right in the ballpark for engineers and architects. We learn (if we're paying attention we learn this early) that the boundary conditions need to be explicit, or they'll be fail points. Then we learn that it's the boundary conditions and interfaces and integration points! We pay attention to the (Booch) fundamentals, the separation of concerns, the abstractions, the balance of responsibilities, and then we have to watch those interfaces! And watch for holes in the fences!  Rabbits. Mixed metaphors.

Interfaces! The strength and the weakness of systems! Parts, chunked according to the paradigm du jour (components, services,...), give us realms of intellectual and organizational control--units of innovation and experiment, units of expertise, units behind the walls of which we can simplify and refactor and otherwise manage (or not) "technical debt" or local integrity of the part. Ah, but parts needs-must collaborate to produce system outcomes, and therein lies the rub. Literally, for many physical systems. But no less truly for software systems

10/4/09 Visualized in His Mind's Eye

Dana told me the story of the Raurimu Spiral in New Zealand, and I looked it up. Howitt's telling of the story is quite charming! We have lots of stories like that in software. Our heroic integrations no doubt influenced this xkcd.

By all accounts Holmes visualized the layout [for the Raurimu Spiral] in his imagination. --wikipedia

The reason Raurimu came up, is that we were rambling in the IU Research and Nature Preserve bordering the Griffy Preserve, and part of the trail goes along an abandoned railway cut. The cut goes through some quite challenging terrain, and must have been expensive--and onerous back in the days it was done. The striking thing is, it ends where a bridge was obviously planned. But it would have to be a long and high bridge to cross the span at that point. The story has been lost in time, but either they made some very serious engineering misjudgments (it sure looks like they did!) or they ran out of money. Or some of both... This Google satellite image (taken in winter) gives some impression of the span, but not of the elevation at the points that need to be connected.

We're hiking, Sara's grumbling about being bored (amidst all that beauty?!), and I'm thinking hey, this is why the architect has to do more than run out front and lay tracks in front of the train! The architect has to scout out what lies ahead, to know when a bridge will just be too expensive, or otherwise not feasible.

"I found quite a good definition of what a software architect has to do in the audio commentary of one of the Lord of the Rings movies. Peter Jackson described how the script always changed just days or hours before shooting and he compared the script writers to someone who 'ferociously lays down tracks in front of a running train.'

Software architects must ensure that their train (software project) goes in the right direction by laying down the tracks, that it stays on the rails and that it arrives at the destination in time. Passengers (programmers, managers, ...) have to feel comfortable and safe. The train should run smoothly, even in hard weather."

-- On the Definition of an Architect, by Mike, posted on Michael Platt's blog on March 30, 2006.

10/10/09: If you noticed that I just inserted entries between 10/4 and 10/8--yes, I pulled a few entries out of the "pound-down-and-knead-again holding tank"... (It's the entries that I left in the tank that are the reason I decided to create it! Grin.)  I especially like the lesson about the bridge, and the need, in this YAGNI world, for the architect to run ahead and scout out what will be make-or-break.

10/5/09 A Small Window on the "Integrating Acquisitions" Problem

"It will take a few weeks to fully update all of your account history and you will receive an email notification when this is complete. Thank you for your patience and understanding as we combine more than 74 million accounts into one loyalty program." -- email, Delta SkyMiles program  

(side note: I fly by schedule, so I have lots of dis-loyalty accounts. Moms, and I don't just mean Jewish moms, constantly put their family ahead of their personal comfort. Then there's me. I fly by schedule, and use Dana's miles bank to upgrade transcontinental flights. Best of both worlds.)

10/5/09 Resource Manager Patterns

• Pattern-Oriented Software Architecture Volume 3: Patterns for Resource Management, by Michael Kircher and Prashant Jain
• Resource Lifecycle Manager, by Michael Kircher and Prashant Jain
• A Pattern Language for Resource Management in Three Tier Architectures Prashant Jain Michael Kircher
• Partial Acquisition, Prashant Jain and Michael Kircher
• Eager Acquisition, Michael Kircher
• Lazy Acquisition, Michael Kircher
• Resource Management: Interview with Prashant Jain on Software Engineering Radio
• Resource Manager Pattern: manage multiple resources of the same type. (EventHelix.com)
• Resource Allocation Schemes (EventHeliz.com)
• Workflow Resource Patterns, Nick Russell, Arthur ter Hofstede, David Edmond and Wil van der Aalst
• Resource Dependency Manager Pattern, Thomas Reicher, Asa MacWilliams, Bernd Bruegge

There are only two or three human stories, and they go on repeating themselves as fiercely as if they had never happened before.

-- Willa Cather

10/5/09 Inspiring Stumbles!

I stumbled upon this wonderful site: Portal to the Universe. I guess it is to astronomy what Matter Network is to the environment.

And have you seen this--high school kids have built a diesel-hybrid race car that goes from 0-60 in four seconds. The car currently gets 60+ mpg, but the students hope to break 100 mpg so they'll be eligible to win the Automotive X-Prize. Wow! High school kids!

10/6/09 We Made the History!

Alerted by one Grady Booch's slides, I went to the OO[AD] History Map on wikipedia. It's cool that Fusion, and even Team Fusion, made it onto the map. Actually, I think the map should show Fusion feeding into the UML because Reed Letsinger from our Team Fusion team was on the UML core team (led by the "Three Amigos") but also because Fusion created the idea in the mind of the OO community that these different approaches were complementary and worth, well, fusing. Grady Booch (Booch) and Jim Rumbaugh (OMT) and Rebecca Wirfs-Brock (RDD), among others, did ground-breaking work, and Derek Coleman and his team moved it forward in important ways (OOA and D, structure and behavior, etc.). Of course, I am biased by the unique perspective I have, and the gratitude I have for the shaping influence Derek Coleman and Fusion had on my outlook and career. If I had to draw the roots of VAP, Fusion, it's antecedents and [the] UML would be most prominent, as well as Evo Fusion (Todd Cotton's blending of Tom Gilb's EVO with Fusion to create an early and profoundly influential iterative and incremental process). Fusion, Evo Fusion and architecture were the three "legs" of Team Fusion. I should also say though, that Grady Booch's Object-Oriented Design (1991) was a watershed event for me, like so many of us who'd launched into object-oriented development in that timeframe--it gave us a much better understanding of what we were doing, and thinking tools to manipulate conceptual constructs and reason about systems with a quite different structure than the procedural paradigm we "grew up" in.

10/6/09 Workshop Update

The Software Architecture Workshop we are teaching in The Netherlands in December has only 3 spots open (some that are tentatively "taken" may open back up; lots of budget uncertainty in this economy!). Still, if you want to take the class in Europe this year, I suggest you act fast! The class is being run through ESI, and you need to enroll directly with them. Dana Bredemeyer is scheduled to teach that one. When clients want Dana over me, I tell them I'm fine with that--I think he's great too. Mostly they have no idea just what that means. :-) But, one of the architects enrolled in the upcoming open enrollment workshop I'll be teaching in Chicago in December, sits across from an architect who has taken both the Software Architecture Workshop and the Role of the Architect Workshop from me. It's neat when an architect recommends my workshops to himself (takes a second) and his peers! This is important because we do no marketing and sales (beyond reminders here and on the Bredemeyer Resources for Software Architects site)--and it works, since more than 80% of our work every year is with clients we've already worked with.

10/8/09 Why We Need the UML! (Metaphorically Speaking)

Not that you need any persuading, but I thought this is a neat demonstration of the need for visual language:

• Christoph Niemann's  "How to Please Elise"

I've used Gyorgy Ligeti’s abstract graphical language for music notation to make related points (in the Role workshop), and came across this:

• ☼Ligeti - Artikulation♫  (the visual listening score for Artikulation was created by Rainer Wehinger in the 70's)

I'm battling a virus (of the make me sick sort) so I'll just leave you with this link on visualizing music.

10/8/09 Ready for Tomorrow?

"To exaggerate somewhat--but only a little--anything is possible with software, if not today, then tomorrow."

-- Does IT Matter? An HBR Debate, HBR, June 2003

10/8/09 To Be or Not to Be (the Local Community Tech Hero)

• To be
• Not to be

10/8/09 Bezos Says It Best: Strategy Should Happen Fractally!

Alan Kay has served me well too!

1/2/10: Then again, xkcd is acute, as always (remember to scroll over).

10/8/09 On the Mend -- or at Least Enough to Think Optimistically!

I was knocked off my feet by a virus (or something) for the last two days, and this is just not something that happens to me (well the last time was December 2006)! And I distinctly do not like it! Lots of time to think, but no tolerance for movement, light or sound which just left me inside my own head! I wish I had time to jot and sketch some of those ideas for you, really I do. But now I'm two days off on my tight schedule!

10/9/09 Wait a Minute!

I tried the "I'm feeling lucky" Google search on "ruth malan say next" -- it works!  I still don't know what she'll say next, but Google's already on it!

Ohhhmmmmm! 

So I tried "think optimistically architecture" and my journal comes up second--with an entry I wrote last night! (Ok, I had the date wrong yesterday--it's disorienting to have two days stolen right out from under my feet.) Google will take a lot of beating, because Google invests heavily in its trawling, not just its algorithms!

I use Goodsearch (riding Yahoo!) as much as I reasonably can (I'm trying to set an example for the other families associated with our kids' school, who so far are disengaged), and that gives me a window on how superior the Google algorithms are! But, Goodsearch has a winning idea--share half the proceeds of siphoning off do-gooders search traffic with the do-gooders' non-profit-of-choice. (There are many angles on diverting cash from corporate and individual purses. You've just got to get a little ingenious. And then even Google has a potential Achilles' heel.)

Back to "think optimistically architecture" -- I like the result (The Optimistically Critical Architect)  that comes up first! I do find that there are ways of asking questions that are thinly-veiled criticisms, and there are ways of asking questions that are oriented towards understanding and collaboration. There are also ways to embed the question into the process, so it gets raised by a neutral process step. Like, "walk us through how this design meets this goal (or principle, etc.)" is a process-driven break-point where the team often finds gaps and inconsistencies for themselves, or collaboratively with architect reviewers. If the architect wants to be a hero, the architect will find problems and fix them--in a way that makes it clear that he's the one with the smarts. If the architect wants to be a leader, the architect will find ways to empower the team to achieve excellence. I want to highlight this sentence, for Adam puts it way better than I (and I've made numerous stabs at it):

"We must communicate our views—sensitively, whenever possible; bluntly, when necessary; and harshly, never."

-- Adam Bonanno, The Optimistically Critical Architect

As far as the writing goes, De Bono's Six Hats doesn't leave me stunned (the style is dogmatic and it is quite repetitive; oh, don't look at me, I know this pot is black!). But as good ideas go, paying attention to cycling through the states that the 6 hats represents, is tip-top! In particular, I'm referring to the black hat (objective, critical, etc.) and the green and yellow hats (exploratory) and the red hat (emotion and intuition). The white hat (just the facts, nothing but the facts) and the blue hat (process) are critical too. I just mentioned the black versus green/yellow/red hats as ways to help surface problems and opportunities in a more team-oriented way. (The idea is everyone has to participate in every "hat" state.)  

10/11/09: Context: Lest you think this post was prompted by self-absorption, I'll explain the context. I tried Goodsearch on the Nobel Peace Prize news early on the morning of the 9th. Nada! Zip! So I tried the same search phrase on Google. All the breaking news. So I thought: ok, Google is right on breaking news, but how about quiet backwaters places? Then I remembered someone doing a "what will XXX say next?" Google feeling lucky search at TED, and I tried "ruth malan say next." That was worth a chuckle, but still didn't answer my question. So I picked my last entry from the night before and added architecture because "think optimistically" was too generic to be fair, and wallah! My site was second. Now you know exactly how my mind works. I don't know why I thought to test Google on the future before the immediate past. But you do. You, and Google no doubt. 

10/16/09: Of course, this was an example of the observation effect (I do like Darth Don's "Meta-Architecture Introspection Paradox") applied to Google searches--having written this entry, it is what now comes up when one Googles "think optimistically architecture"!

10/9/09 Nobel Peace Prize

Today, Obama wins the Nobel Peace Prize and with it a message from the world to: "encourage his initiatives to reduce nuclear arms, ease tensions with the Muslim world and stress diplomacy and cooperation rather than unilateralism."

Dana, seeing a picture of Obama earlier this week, groaned heart-wrenchingly "He's aged 10 years!" Working against resistance, often potently negative resistance, is spirit-wearying. It is so great that the world is sending this message to Obama--and to all of us: hope and concerted, unflagging action towards making this a better world is a top global priority and America has regained recognition on the global leadership stage for tackling the huge moral imperatives of our time.

10/9/09 SATURN Call for Papers

"Carnegie Mellon Software Engineering Institute SATURN 2010 Conference Call for Proposals Now Open Deadline for Submission is November 9, 2009

October 1, 2009 - Pittsburgh, Pa., - The SEI Architecture Technology User Network (SATURN) Conference 2010 brings together experts from around the world to exchange best architecture-centric practices in developing, acquiring, and maintaining software-reliant systems. Architects at all levels meet to share ideas and lessons learned, network, and learn about new and existing technologies.

Call for Proposals Now Open

The SATURN 2010 Conference theme is Architecting for Change. The SEI SATURN 2010 committee is seeking experience reports and discussions of architecture methods, techniques, and practices that enable organizations to continue to meet their business and customer goals in the face of persistent change. Topics of interest include, but are not limited to o  managing system evolution through architecture-centric practices o  preserving architectural support for important system qualities while moving to new technologies o  case studies of architecting for change o  techniques, methods, tools, and processes that support the ability to design for change o  economic and managerial considerations for architecting in a changing environment o  architecture reconstruction and conformance o  dealing with technology obsolescence o  using agile or open approaches to deal effectively with architecture in a changing environment o  staging architectural decisions to account for resource constraints and changing business goals o  enabling change through self-adapting systems

Deadline for Call for Proposal Submissions is November 9, 2009.

For more information visit the SATURN 2010 website at www.sei.cmu.edu/saturn/2010."

10/9/09 XKCD

Everyone (I like) loves xkcd (at least most of the time) and this one is one of my all time favorites! Very astute--for a guy. ;)

10/10/09 The Devil's Dictionary

Going back to The Devil's Dictionary for quotes for the leader page to some new competency modules, it occurs to me--forget workshops! I think an architect could do well just living by the definitions in The Devil's Dictionary!

Guidelines for the Architect:

COMPROMISE, n. Such an adjustment of conflicting interests as gives each adversary the satisfaction of thinking he has got what he ought not to have, and is deprived of nothing except what was justly his due.

CONSULT, v.i. To seek another's approval of a course already decided on.

CRITIC, n. A person who boasts himself hard to please because nobody tries to please him.

DECIDE, v.i. To succumb to the preponderance of one set of influences over another set.

DELIBERATION, n. The act of examining one's bread to determine which side it is buttered on.

DISCUSSION, n. A method of confirming others in their errors.

LOGIC, n. The art of thinking and reasoning in strict accordance with the limitations and incapacities of the human misunderstanding. The basic of logic is the syllogism, consisting of a major and a minor premise and a conclusion — thus:

Major Premise: Sixty men can do a piece of work sixty times as quickly as one man.

Minor Premise: One man can dig a posthole in sixty seconds; therefore —

Conclusion: Sixty men can dig a posthole in one second.

This may be called the syllogism arithmetical, in which, by combining logic and mathematics, we obtain a double certainty and are twice blessed.

REASON, v.t. To weight probabilities in the scales of desire.

REASON, n. Propensitate of prejudice.

RECONSIDER, v. To seek a justification for a decision already made.

Guidelines for the Architecture:

ABATIS, n. Rubbish in front of a fort, to prevent the rubbish outside from molesting the rubbish inside.
(see also "facade," GoF)

RESPONSIBILITY, n. A detachable burden easily shifted to the shoulders of God, Fate, Fortune, Luck or one's neighbor. In the days of astrology it was customary to unload it upon a star.
(this relates to refactoring, which, given the preponderance of intent over action, may be defined as shifting the responsibility to factor onto Fate, Fortune, Luck or one's neighbor.)

Business Intelligence:

BAROMETER, n. An ingenious instrument which indicates what kind of weather we are having.

Organizing for Architecture:

ACCOUNTABILITY, n. The mother of caution.

Ok, so you catch my drift.  Next time you use models to reason about the system, you'll think of me, I mean this.

And then you'll remember it was I who burdened you with pessimism:

PESSIMISM, n. A philosophy forced upon the convictions of the observer by the disheartening prevalence of the optimist with his scarecrow hope and his unsightly smile.

Then again, just as pessimism was being thrust over you, I do this, and remind you why it is that you read here--that little word at the bottom of Pandora's box!

I'm really at my best when I'm avoiding work! It's too bad there's no money in it!

Hey, if someone (other than Daniel, Charlie and Scott) paid me a compliment about this journal, you could get on my case about enjoying that. But, given your silence, I'll prompt you: don't you think that's the best definition of refactoring you've come across--ever?!!!

What's that? If I want feedback, I should blog? Ok, blockhead, I don't want feedback. I want positive feedback. No, I'm kidding. I'm perfectly happy just talking to myself. In fact, I'm like 5 9's sure I'd prefer my own (positive) feedback to yours. ;) So we'll just go with "that's the best definition of refactoring I've come across--ever!"

Now you just have to read this McCloud comic (given that you probably didn't read it when I pointed it out to you the other day). But when you wonder if I have my shift together, think on this: you're reading this! One has to wonder--about you!

Shift? Yes--updated as Did You Know 4.0. But it's also a reference to the right hand side of this MacLeod cartoon...

And if you don't follow my links, you have only yourself to blame when you miss the good stuff! And that shift is really good! The earlier versions too. And you get a good impression of how quickly the shift is shifting (and what stays the same), when you look across the revs over the years! (2006, 2007, 2008, 2009)

That's all I have to say. Have a great weekend... I have to work now... [Where did I put that "pound-down-and-knead-again holding tank" anyway?]

Ok, ok, so the refactoring intent-over-action thing doesn't apply to any projects under your purview. Except for the ones you had to take over from someone else... I rest my case.

10/10/09 Elements of Architecture

Given my propensity to an excess of words, I even more distinctly admire Grady Booch's talent for distilling the simple, memorable, actionable essence from a complex web of truth: 

"The code is the truth... but not the whole truth...

• Architecture as a collection of significant design decisions

• Patterns as themes

• Cross-cutting concerns as traces

• Rationale as the backstory

• Tribal memory as the human story"

-- Grady Booch, Elements of Architecture blog post 10/10/09

Isn't that great? Phrases like "rationale as the backstory" are so vivid and memorable they'll become key memes in our field. I also love "tribal memory as the human story." I've used Robert Frost's The Road Not Taken to make the point that our rationalizations of our history reveal and shape who we are. Kathie Sowell uses the same poem to talk about different path options going forward, leading to the same destination. So tribal memory shapes the human story. And the human story builds not only systems but the tribal memories that are wrapped around and within those systems. And we reconfigure our past, as we configure our future. It's all very complicated and messy and human! You see why I like Grady's version? Essential, elemental. And open to rich interpretation... ok, ok, I'm done.

"Cross-cutting concerns as traces" reminds me of Gerrit Muller's concept of qualities as integrating needles. Gerrit Muller is another of those stand-out giants (he is tall, but I mean in intellect and spirit) of architecture and systems thinking who have much influenced and informed me. Gerrit is also a wonderful man, and we've enjoyed having him visit (along with his wife)--although it has been a while; too long!

And I would be remiss, as I enthuse about Grady's succinct capture, if I neglected to add that I also loved Charlie Alfred's 4 b's of architecture: being, behaving, balancing, and becoming. If you are familiar with Martin Fowler's reference to his wife's caricature of building architects (they take care of the 3 b's: bulbs, bushes, birds), then you will recognize that Charlie (in cahoots with Gerry Weinberg) adds a dimension of humor. But, that is one of Charlie's hallmarks.

10/10/09 Innovation in Concept

I'm too busy working to read this, but it looks interesting--my gloss produces the ah ha: innovation in concept is an essential part of the innovation process. Post-it notes were invented by an accidental creation of a removable glue, and then the idea to use the paste to stick markers in hymn books, and from there to sticky notes. So the concept arose in conjunction with a "failed" experiment, but the experiment would have ended in the trash-can of obscurity if it weren't for the invention of a use concept to go along with it.

10/11/09 He's Made A Friend of Me!

Did you read Darth Don's Archetrons post? Here's a peak:

'You can either measure the current state of the architecture or observe the progress of the architecture team. You cannot observe both state and progress. For example, asking for an architecture review gives you the state of the architecture topic but changes the progress itself — the team had to stop working on the project and produce the presentation. Moreover, the act of producing the presentation causes the team to think about what they are doing, and inevitably changes the direction they were heading. This phenomenon is the Meta-Architecture Introspection Paradox.”

-- Donald Ferguson, Archetrons, 10/9/09

Now, if it were me, I would have said "we all know that it is better to fail fast and cheap, because every success comes at the price of a path littered with failures. Ok, so we're going to count failures, and time to failure, and reward failures--especially fast failures, and reward those who help cause failures, so they happen fast, and cheap. This is an architecting processes vetted by The Open Group. It's called VAP. When it's applied to IT, it's called VAP-IT. It fits in quite well with our Darth Don character, really. Oh, for those who are incredulous, you'll find it on the Bredemeyer site."

Now you're going: did she say that with a straight face? It so could go either way.

Hey, I told you, I can do this thing with words.

(Not to be repetitious or anything... but if that Fluffy Easter Bunny-wielding grammar-corrector should consider coming after me for my missing article, we'd want him to know just who he's messing with. Yeah, someone who can pull articles out from under you and trip you up, just like that.)

10/11/09 VAP according to Bierce

Here's VAP in Bierce:

You see, it really helps clarify things when you boil them down to just the essence!

If you're intimate with VAP, you'll understand that the parody is perfect, just perfect!

10/12/09 From the Mouths of ... Monkeys

Today, Ryan told his friend: "There's a fine line between appropriate and inappropriate, and then there's the whole category of stuff you just don't do!" I immediately thought of this journal. I wonder why... Ciao! 

Btw, Ryan's website still comes up first on a Google search on "handmade flies" and second on "flopping fish." We read the stories from the childhoods of leading entrepreneurs like Bezos. It is neat to watch from the other direction--where will the kid who does this end up? One just doesn't know. At present, swine flu is making its rounds of Bloomington schools... So much lies between now and then! An architect friend (Matt Johnson) said to me when Ryan was born: "it's like having your heart run around outside your body" -- and you can't protect it, or tether it. This is true with anyone you love, but kids are so reckless! 

10/13/09 How Loudly Speaks the Lean of a Baby!

If this picture doesn't kick us into life-changing gear, what will?

10/13/09 Great Collaborations!

Returning to ☼Miriam Makebe and Paul Simon♫, I'm reminded that it is such a moving example of what diversity and great collaboration can produce! I love that about bands that just work--there's so much evident fun in the collaborative flow of the moment, and it is so productive! And for me, that is a visualization of software development when the team hits that "flow" where everyone's strengths and vitality blends to produce remarkable software. Creating the context that makes that possible is not a project management task. The people side factors, surely. But it is a matter of just-enough structural and strategic context so that the team flow, the collaboration, is productive of great work. Without it, there may even be a feeling of camaraderie--at first... but the net effect of turbulent churn erodes that goodwill. In short: chaordic, good; utter chaos, bad.

10/13/09 Leader Leading

We have recognized in STEM that we have a problem: as we move at hyperbolic speed into the future, we need more people, not less, being inspired to enter engineering (including software engineering) and computer science. So, our (collective) thanks go to Grady Booch for creating his ☼Why Engineering?☼ video--it is inspiring and wonderfully creative! In a word: awesome!

10/13/09 Leaders are Made by the Need They See

"Let me be clear: I do not view it as a recognition of my own accomplishments, but rather as an affirmation of American leadership on behalf of aspirations held by people in all nations," President Obama, October 9, 2009

I've been making the point for some time (but it is still crystallizing, so bear with me) that leaders are made by the need they see. That is to say, no matter what the personality or the presence or the talents or the weaknesses of the person, once they see a need they are compelled to do something about, they find within them the ability to lead. Now President Obama is a great and vibrant speaker, but we have shy people like Mark Zuckerberg stand on the plate of leadership because he is passionate about the opportunity to make a difference by addressing the need he sees. The need (or the opportunity) compels. It energizes. And it overcomes.

I tease myself about my too many words, but I too try to find the essence. The better-than-Pareto lever to move our world. I've worked with leaders across industries and across IT and product development, and I've read and read shelves full of books on leaders and leadership, and I land on that: leaders are made by the compelling need they see. So if you're not leading, you need to be looking! Looking for that compelling need. I don't mean looking in someone else's job! I mean looking within your purview. If your world is a mess, you need to make it less so. If it is not, you need to make it so! Architecting is about the delicate balance between taking on too much, and not enough! About structural integrity and pushing the boundaries on value created, which pushes and frays at structural integrity. It is, or should be, about striving for balance in the context of tension! (Though not in an ill-humor and ill-health kind of way, of course.)

Mentioning Mark Zuckerberg draws me back to the infamous SXSW interview, and I wonder at the audience not being interested in the way the man thinks about his role and why he chose to remain CEO of Facebook and what he does with his vision notebooks! Because what made him a tech star is his tech savvy applied to a vision. That technologists simply discount that--simply, out-of-hand treat that like it is BORING--astonishes me. Technology is nothing if it doesn't serve. An API is nothing if it doesn't connect to value. The more technologists open themselves to this insight, the more they will contribute to the innovation, the invention and development of value, that will see the business they work for through wave after wave of creative destruction. And wave after wave we must anticipate! Because there are Mark Zuckerbergs in this world!

And maybe some of the "Zucks" of the next generation will have been inspired to enter software engineering or other STEM fields by Grady Booch's ☼pitch☼ to high school kids and students!

10/13/09 Patent Storm

Daniel Stroe pointed me us to this: The Mother of all Software Patents.

10/15/09: Daniel added this link:  Executable Content, Software Patents, and Here's Your Subpoena, by Jon Erickson

And observed: "bottom line is that you cannot earn money writing software without a good understanding of the legal aspects of the technologies that you are encountering."

I do agree that patents are architecturally significant, and when we are doing Competitive Landscape Map-related investigations and synthesis, I encourage architects to scan patents (later too, as design alternatives come into view). This is an aspect of the value chain that Marketing isn't watching, and Legal can only be called in to deal with specific questions--they aren't intimate with our own technology capabilities (other than what we ask them to investigate and protect), nor are they necessarily aware of capabilities our competitors may be leveraging (they should know which our competitors control!), or those we might conceive of building. But I have been surprised at how often I encounter sheer naiveté about patents among architects within some organizations. Indeed, some organizations are very aggressive about patents, and others quite laissez faire--so I conclude that it indicates that a company has an identity (or self-concept) as an innovator when it is actively inventing and protecting its inventions. I wonder, as do many, if the whole thing hasn't been taken so far as to do more harm than good. To what extent are concepts being patented over designs, and fundamentals of a field over unique company contributions to an area of competitive capability? In pharmaceuticals we have debates that rage around the ethics of protecting a life-saving drug from the competition that drives costs down. Here we have questions around the public-spiritedness of protecting a design paradigm that changed the face of the web. Regardless of the bigger questions, patents are a fact of life, and yes, we should be more savvy about where our vulnerabilities are, and where we could create a protectable opportunity. I expect the widespread impact here will raise awareness.

11/2/09: Desert storm--the mother of all battles... So: The mother of all software patents-->patent storm. Oh, right... that was 1991. Some of you were still in (elementary) school then! Groan!

10/14/09 My Scout, My Hero

It occurred to me that while my playfulness has been pressure-relieving for me, it transferred the pressure of slipping time to you. Pressure, that is, at least to filter better. Well, I was we were rescued from my sandbox of dissolute playfulness by my much-valued scout (yes, Daniel; and no, that is not his characterization, but mine), who pointed me to these:

• Unsung heroes save the net from chaos
• Jonathan Zittrain: ☼The Web as random acts of kindness☼

10/14/09 System Architecture

System architecture is about the design not just of the parts but of the relationship among the parts, for it is in the collaboration of the parts that value is created. Or eroded. Alternately put, new value emerges from the collaboration of the parts, that is not inherent in any of the parts alone or even in uncoordinated conjunction. This is why "we must architect across the interfaces," across the "seams" in the system. [Rechtin; Ackoff; etc.]

But that's not all, is it? Value is also created or encumbered, even eroded, in the relation of the system to it's context, or its various contexts. And the architect must architect across the boundaries of the system--to the extent that the degrees of freedom allow that. (More, usually, than architects are given to think, because we have been shut out from that negotiation of the boundaries by our waterfall processes and division of labor/role specialization.)  And regardless, there's architecting the relationship of the system to it's context, even if the context is ostensibly immutable.

So architecture encompasses decisions about the (architecturally significant) parts and their relationships, and the relation of the system to its context. Its technology environment as context. Its various use contexts. Its business context.

And when you turn that into a process, you have to reverse the order--first. But then you play it "forth and back.'

At the other extreme from an (intentionally) architected system, is a fully accidental architecture--emergent to the extent that pieces are agglomerated over time. And even in such an accidental and emergent architecture, the value that is created by the system (and all its collaborations among the parts) is greater than the sum of the value of the parts. That is, some new, additional value has been synthesized. Potential new costs and challenges too, but on balance, greater value. At least, for a while. The thing is, the system becomes embedded in its context. There is inertia and dependency in that embedding.

Whether intentionally designed by the human mind, or designed by the chances of fate and the playing out of the web of interactions between the context and the parts, architecture has to do with the parts (well-formed or eroded) and the relationships between the parts (clean and simple, or messy, conflicting and prone to error and surprise) and the relationships with the context (again, clean and simple or promiscuous and sloppy).

Which is why we architect.

Oh yes, a note may be in order: when I say structural design I absolutely mean structural and behavioral design for we must not, should not, cannot design the structure without designing the behavior! And we would not--not unless we haven't been paying attention to the lessons of our field's evolution...!

But here's a thought: might we say that architecting is about designing how value will be created and delivered by the system? While keeping a strategic eye on the horizon of other use contexts and the future. (I say this because our architecture definitions tend to ignore value, like that's just happy accident or someone else's job. Then that someone else is upstream. And we're back to waterfall and role cleaving and tradeoffs that are made upfront, with little sense of the downstream impact. Which is to say, we split design into "outside" and "inside," or "user facing" and "system internals," and then we're back to the issues that this unnatural cleaving produces.)

In sum:

• Value lies not just in the parts, but in the relationships of the parts to each other and to the context.

• Architects design to create and shore up value. In its first incarnation, and through the evolution of the system

Of course, the insight about the relationships among the parts and to context is not new. Bucky Fuller was saying this way back when. Except not quite in these terms. My terms, at least, are for the most part unique.

10/15/09 More Bumper Sticker Wisdom

Each of us is UNIQUE

Just like everyone else

10/14/09 Software Architecture Document and VAP Action Guides

Note to self: revise our Software Architecture Documentation page on the Bredemeyer site. And the Visual Architecting Process Action Guide page!

(Sara, letting go to brush leaves out of her hair, fell off the swing. She got up, dusted herself off and said: 'Note to self: don't brush off leaves while on swing." I thought "How can a child smart enough to say that, be stupid enough to just do that?" But the turn of phrase stuck with me, apparently.)

10/14/09 Software Architecture Dashboard

It is more easy to joke about the "economics of software architecture," than it is to get a handle on a good generic radar for architectural accountability, progress and contribution. The work I did on the "economics of software reuse" taught me that the models provide an indication of sensitivity points and critical factors. But it is hard to go beyond that, because, the metrics work of the likes of Bob Grady and Capers Jones notwithstanding, we just don't generally have good data to plug into the models. But, should we give Architecture Governance Boards more to go on than archetrons? Economic models that illuminate the factors that play into an analysis of architecture costs, benefits and opportunity costs? And a sense of what to measure, if a radar or dashboard is desired. We advocate linking architecture scorecards to strategy (at that level of scope) and goals/objectives at that level of scope. The dashboard design is dependent on the specific goals, not generic benefits, costs and opportunity costs.

Still, if we can come up with key factors and associated metrics, interested governance boards can then require that projects keep track of this data. This would feed into empirical analyses of  the economics of architecture, and mature both the projects involved (they'd be able to estimate and navigate with more assurance) and our understanding of the field. BUT, and it is a bigger "but" than the caps belie, it is very hard to get projects to record data that isn't easy to collect and/or where the benefit is long term, not immediate.

• Economics of Architecture-First, ♫on architecture No. 9, Grady Booch [as best I recall, this speaks to the value side, though in general terms]
• An Economic Model for Software Architecture Decisions, Paul C. Clements 
• Economics Driven Software Mining, Rami Bahsoon and Wolfgang Emmerich [the idea of applying the Freakenomics approach is interesting]

Aside: We use the concept of "teams and themes" in the architecture scorecard/dashboard work, in communication planning, etc. These themes provide traceability (to higher level strategic initiatives and associated goals) and alignment (of subsequent decisions like pattern choices). Themes... which brings me to temes. Personally, I like the notion of patterns as temes (or technical memes)--the replicators of a structural unit within a system and from one system to another. So, teams, themes, and temes. :-) 

Well, as soon as I get my archman donation out of the way, I'll have to return my discretionary time slices (ha!) to updating our VAP Action Guide chapters and progressing that whole body of work!

10/15/09 Tribal Memory

When Dana talks about becoming interested in architecture, he tells of his first project in the Operating Systems Lab at HP. He had to take over a piece of the system that was half done, with no documentation. The "what was he thinking?!" question that came up over and over, too often had no answer, as the designer-developer in question had left. That was one shaping influence. Others included spending summers with Russ Ackoff and Bucky Fuller, respectively, when he (Dana) was an undergrad. Yes, our Dana is an unusual sort of nerd. One that was discovered by the HP recruiter in the CS computer lab dungeons at IU. (Smart recruiter! He figured that the developers HP most wanted, were so busy writing code they weren't schmoozing at the job fair.) But one that took summers to go figure out what Fuller and Ackoff were up to in the system thinking arena. So, in the 80's Dana already had the title of software architect, and if I ever come back across his business card from that era, I'm going to frame it to preserve that evidence that HP already had an OS architecture lab with designated architects back in the 80's.

Yes, I'm pretty sure we still have it. Dana is even more of a pack rat than I am. I'm afraid that arriving in a country with but two suitcases and no "history" save for one technical book and one book of poetry, sort of does that to a person! At least, it did to me. As for the book--there is a story there too. It was Mary Loomis's book on database design. It was already out-of-date by then, but it was one of my shaping influences ("it's all about information, stupid"), so that is what I chose to bring. The poetry? Seamus Heaney's Field Work of course! Duh! But back to Loomis. Guess who was manager of the Software Technology Lab at HP Labs when I joined? Yep, Mary Loomis! Funny thing is, I am such a flatlander and so ignore author-as-personality (in the People sense) that I just knew my database book as "Loomis." So it was a while before I realized that Loomis was Mary Loomis! At any rate, I still have my Loomis and my Heaney, and I'm pretty sure we still have Dana's business card. But just as layers and layers of code changes obfuscate the intent and the design, so does the accumulation of more of the "pebbles" of life's memories and mementos. Why, just on base of my monitor I have my Earth's scream and a crinoid fossil--a symbolic combination that happened by accident but is a perfect call to action every day!

Well, that was my long-winded way of saying that tribal memory is very faulty! It is awesome, and I--you know, the "software development is a socio-technical endeavor" person--put a lot of stock in the ability of people to create highly generative "flow." It is fun, it is productive. It is doing. But it is also the undoing, if we don't apply discipline to maintaining the design as design. That is, in part, why I think it is unfortunate that we have coalesced towards saying every system has an architecture, even when it wasn't designed--when it is the accretion of accident not intent. This is not at all a distinction between upfront design and evolutionary design. It is a distinction between a kludge and a design. Given architecture as design, we can add the concept that the design, for any complex system that lives and livelihoods will depend on, ought to have a manifestation not merely by implication in the built system, but in design artifacts.   

My fallout from Darth Don's archetron (verbal) sketch was several archman cartoons falling under a theme of "economics of architecture." Looking around for more grist for the spoof-mill, I dipped back into that topic (some of the trace lies in the entry yesterday). Relevant? Well, I was too lazy to dig out my IEEE login and besides, if I listen to Grady's columns I can double-task, right? Well, so it was that I distractedly clicked the column above Grady's "economics of architecture" piece, and was already into it when I realized he wasn't doing economics at all. He was covering a "building architecture" analogy, and in particular the story of architecting his own house. I've seen the analogy covered various ways, but Grady does an especially good job of it. He uses the story to make important points about visualizing through models to support reasoning and "test" the design (finding flaws that would have caused expensive rework if discovered during construction), and the importance of evolving the design as changes were made and elaborations added. I liked the story, and its use.

Tribal memory is woven through with the stories we tell to sustain the culture of the tribe, and preserve the memory. Stories. And our rationalizations of then, from the vantage point of now. It is ad hoc. It is inconsistent and threaded with inaccuracies. And it is highly accidental. It is essential. And it is not enough! Not for systems that our business depends on now, and into the future. Tribal memory is vibrant. But we can make the formal "memory," the pictures and documents, vibrant too. We don't want to replace informal people-rich process, but rather to support it and provide leverage. And that is the essential point in the economics of architecture, isn't it? Leverage. We invest some in expressing the design as design, to leverage the architectural thinking across the "tribe" and time, and keeping the design current enables us to sustain leverage.

10/15/09 Structure and Self-deception

Now, you surely recognize that this journal bears witness to the enormous gravitational pull of accidental structure! Simply moving with the flow of thought is seductive. And it is fun and satisfying, with a quick sleight of mind, to pull the structure into alignment. Easy enough to do, while it is small, and discrete, and we can hold it all in our mind. And therein lies so much of the self-deception in software. The personal process does not scale--on its own.

This, by way of Grady Booch:

"The brain has its own language for testing the structure and consistency of the world."

-- Carl Sagan 'A Glorious Dawn' ft Stephen Hawking (Cosmos Remixed) by John Boswell

Here's more of the lyrics:

"But the brain does much more than just recollect
It inter-compares, it synthesizes, it analyzes
it generates abstractions

...
The brain has it's own language
For testing the structure and consistency of the world"

But what the brain does is still pretty effectively encapsulated, despite advances in BCI research. Unless we speak and write and draw and create models and make stuff. Going from the language of the brain to code is productive, and some developers find they are more effective doing that than creating intermediate models. Others couldn't get by without modeling in some form (sketchy or more formal) first, at least sometimes.

Reliance, though, on brain to code as the only mechanism for bleeding thoughts through the encapsulation boundary, breaks down when the system needs-must be built by several people, and more so, the more people. 

So then we get to pictures, and I raked that turf in the PICTURE IT presentation so I won't go back over that. If you can't stand to watch it, you can read what I planned to say.

(Of course, PICTURE IT is in caps so that it can go both ways: picture it and picture IT. You knew that.)

PS: I hope you followed that Carl Sagan link; it's wonderful!

The visualization resources list is ever-growing--and not done. So please do let us know if there are tools or approaches we should include in the set.

10/15/09 Call for Papers (with Interesting Questions!)

"Abstract Submission Date: 29 October 2009 Articles Due: 11 December 2009

The Great Recession Fallout: Will CIOs Be Elevated or Exterminated?

TOPICS OF INTEREST MAY INCLUDE (but are certainly not limited to) a combination of the following:

* Will CIOs need to step back into more tactical activities? Or are we at a deflection point where the combination of possibilities and environmental demands will require more CIOs capable of finding and delivering strategic benefits?

* Will some industries be slow or no-growth ones and some be fast-growth, requiring different skills from CIOs? Which industries and their CIOS are likely to be unaffected? Which are likely to be dramatically altered?

* Will the focus for business shift more persistently towards global versus North American opportunities? Will larger multinational companies rely on more international CIOs instead of North American CIOs? Will we see more line-of-business leaders taking the IT reins away from tech-oriented IT leaders?

* Will this economic downturn set the stage for the next round of more massive centralization of IT? Or will the prevalence of hosted solutions encourage more decentralized and federated forms of IT management?

* How will local and state government CIOs fare in 2010? Tax revenues lag well behind in a recovery, following long after unemployment rates start dropping. This has required governments to look at dropping services outright and finding cheaper ways of delivering old services. Will this recession spur the growth of e-government to encourage cost savings?

* What kinds of skills flourish in this kind of environment?

TO SUBMIT AN ARTICLE IDEA Please respond to Vince Kellen at vkellen at uky .edu with a copy to itjournal at cutter, no later than 29 October and include an extended abstract and a short article outline showing major discussion points."

-- email from Cutter.com, 10/11/09

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.     Topics from the current month are listed down the sidebar (after the archives and before the blogroll). For those who decry my lack of permalinks because you are desperate to share a quote on your blog or to point colleagues to a particular section—just copy the shortcut from the topic link in the sidebar. It's clunky, but it works. I did say the necessary condition was "desperate."

 

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.