Gosh, I often think that since all the important things have been said I can go back to writing code, but I see Maslow was prefaced too!

5/2/08 Iterative and Incremental

In the latest CrossTalk (May 2008), Alistair Cockburn writes on Incremental and Iterative Development and concludes:

"The word increment fundamentally means add onto.

The word iterate fundamentally means to re-do.

Sadly, iterative development has come to mean either incremental or iterative, indiscriminately."

In my experience, people mean incremental and iterative when they say iterative development. In other words, iterative development, as it is used in software, may in some ways be more like the iterative method in math:

an iterative method attempts to solve a problem ... by finding successive approximations to the solution starting from an initial guess

wikipedia

Ideally, this proceeds along two dimensions: learning about the requirements by putting working increments in front of users and successively nudging the system towards user acceptance (making changes to features as misunderstanding or changing needs are uncovered, and adding features); and fixing the structure as the increments get built out and more is learned both about structural demands and opportunities to improve. Ideally. The failure modes that Cockburn describes in his case study pieces reflect mismanagement of the process. Though they start with the best intentions to do the learn/improve piece that is implied by iterative, the project may (be asked to) give up on those intentions under schedule pressure. What we aim to do is multi-faceted—learn/improve and elaborate/add features or services. That is, we aim to take an iterative and incremental approach to evolving the system towards a viable release version. But this can be set off-kilter various ways: too many resets trying to reach feature or structural perfection; or too much weight on feature progress at the expense of structural learning and resets needed to improve structural soundness.   

When I talk of iterating in VAP, I mean repeating the requirements/specification/validation cycle. That is, the action is repeated, though the content or focus shifts as dominant uncertainties/complexities/challenges are surfaced and addressed and a new round of strategies and decisions are investigated and articulated, and tradeoffs are made. It is designedly a learn/improve cycle; that is the whole point of the explicit learn/improve/validation phase of the cycle, and the point of iterating. The philosophy is to cycle quickly, and to cycle through different concerns (the architecture decision model views, as well as other stakeholder concern-view pairings), returning to views to correct, refine, elaborate, refactor, etc., as more is learned about the requirements and different architectural alternatives are envisaged and explored.

I suspect that this is true more generally when iterative development is used in software development--(requirements-design-[code-test-integrate-test]) cycles are repeated on some rhythm: (weekly or biweekly, and [daily]). Ideally. As the system is built out incrementally, how much direction correction, refactoring, etc. is also done, varies from project to project, but the repeating cycle is what is meant by iterative.

So, I think the heart of Alistair Cockburn's message is spot-on. We have two avenues we need to be more clear about in software: incrementally building out our systems; and repeatedly/systematically stepping back to figure out what we have learned and to improve our systems. But I don't think these are mutually exclusive. And I'm not worried about our terminology, but rather about our practices. Frenetic course correction in the medium of code is wasteful and demoralizing. Rather get the course more clear first. Frenetic push to feature release with mounting design debt is also wasteful and demoralizing. Good people leave in disgust. Rather pay it forward beginning with (just-enough/minimalist) architecture cycles that apply agile principles from the get-go—just loosening up the "code" requirement early on, to allow for cheaper/more flexible/adaptable learning via models in the early cycles. Cycles that move through understanding stakeholder concerns and addressing them through views, and stepping back to learn and improve, and later to validate, and repeating, with the focus of the next cycle determined at the architect's discretion. In short, drawing more of the architecture work earlier, so that the duality between system value/user experience design and structural design can be explored, opportunities to innovate through technology can be surfaced and expectations can be set realistically.      

An explicit focus on incremental development reminds me that when we talk about incremental development in software, we are talking about something more complex than just adding on boxes. We're adding to boxes, and adding on boxes, and hopefully not munging the boxes as we do so. More complex projects will need more architecture work before construction cycles begin, because starting with all the wrong boxes costs either in terms of significant rework (design to code) or in an architecture that will quickly succumb to evolutionary pressure, and bring us back to the state that caused words like mung and kludge to become intimately associated with our field.

5/3/08 Randy Pausch's Last Lecture

You may recall that I watched Randy Pausch's inspiring "The Last Lecture" that he did at Carnegie Mellon (transcript). I see that Randy, with the help of Jeffrey Zaslow as his writer, has published a book by that title, namely The Last Lecture. It covers the same inspiring topic of realizing childhood dreams. I need to return to listen to/watch Randy Pausch's Time Management lecture on video (when I'm not supposed to be managing the kids' bedtime). On Randy's blog he admits to being really proud of his number one spot on a Google search on Time Management. I used to be really proud of that with software architecture and then wikipedia knocked us off top spot. It doesn't seem right that a 1-pager on a topic should get top billing on Google's ranking, but that's life. I guess Dana or I just have to get something terminal. Sounds like bad taste from me, but this is Randy Pausch's sense of humor--he said "dying is a good career move," after getting numerous awards these past few months. I don't know how he does it! But keeping a sense of humor through it all, has to be one of Pausch's trademark endearing virtues. He laughs at himself, he laughs at life. He is determined to have fun. He shows us how to live. To live as though we want to minimize our regrets when we turn 80, or when we're told we won't reach 50. In the day-to-day, that may seem excessively morose, but it can be approached joyfully, optimistically. And it forces a prioritizing, value-setting, goal-seeking attitude that positions us to reach our aspirations, fulfill our childhood dreams.

I've used some of Randy's lessons. For instance, his football coach was hard on him and he saw that as a plus because if the coach had seen no promise in him, he wouldn't have driven him hard. Ryan is very sensitive to criticism--his interpretation of being driven hard--and I remind him that it is because he shows so much talent that he is pushed, and pushed to push himself. One of the most important lessons, one that Randy teaches indirectly by example, is the lesson of positive (re)framing. The stories we tell ourselves, the way we choose to interpret events, attitudes, even what people say, has an enormous impact on how we encounter the world. And they are the stories we tell, the stories we have control over. We can shape a whole lot of what happens. We can't not get cancer, if we got cancer, and a healthy lifestyle provides no guarantees. But how we react to what life dishes out, what individuals dish out, is more of our own determining. Our interpretations, our attitude, the things we allow ourselves to think and believe about our circumstances, about others, is in large part up to us. At least, more up to us than some people allow, as they tread a beaten path through life. If we see ourselves as a victim, we are--we are the victim of our own perception (in every possible meaning there).

Martin Luther King was another exemplar of the power to shape outcomes by being absolutely positive, shaping a positive attitude towards circumstance and change that is needed. He saw through the downside to the upside, held out a bright vision of the future, and painted a path to the future in the most positive, most highly-developed human terms. The thing to note, is that that kind of positive reframing is a strong attractor. Martin Luther King learned from Gandhi, Nelson Mandela learned from Martin Luther King; we can can learn from each of them. 

One of the great things about the United States, is that it is, generally speaking, a very positive, very optimistic culture. The New World. The Land of Possibility. It has shaped the psyche of a nation. It is perhaps exemplified in the California optimism that is a fountain of innovative spirit. Yes, knocks come along. But optimism and a willingness to see the positive creates a buoyancy that survives the knocks. I was struck by this optimism, reading Jim Collins article in the latest Fortune magazine; criticized by those who see Joseph Schumpeter's creative destruction as more compelling than Good to Great and Built to Last, Collins reminds us that many great companies can and do last, despite the waves of creative destruction that sweep across industries. They survive because they envisage a future they excel in. No less.      

5/6/08: Daniel Stroe forwarded me this pertinent quote:

Shimon Perez, Israel's elder statesman has described his outlook as choosing to be an optimist, saying "We all die the same way, but we have the choice to live as optimists or pessimists."

And this from the opening chapter of The Opposable Mind:

"The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function. One should, for example, be able to see that things are hopeless yet be determined to make them otherwise." F. Scott Fitzgerald

Sounds like what is demanded of architects!

This, quoted in the introduction to Randy's Time Management talk, is relevant to the self-actualizing thread:

"Talent does what it can, genius does what it must."

5/4/08 Strategy Models

Our Competitive Landscape Map derived from Grove's Context Map and our Visual Strategy Model (which is described in the EA Executive Report we did for Cutter). It pulls together onto one great landscape view the elements that are important to informing and shaping strategy:

• Our market segments: customers by use context, and their goals, concerns, aspirations, frustrations, activities, etc.

• Our strategy: identity, value propositions and capabilities

• Our competition's strategy: identity, value propositions and capabilities

• The Winds of Change: market and technology trends

• Environmental forces and factors: legal requirements and economic forces, etc.

• Uncertainties and threats

• Challenges we face in delivering our value proposition

• Opportunities

The Visual Strategy Map derives from Kaplan and Norton's Strategy Maps, but uses our strategy framework which leads more naturally to a business capabilities model that supports the business strategy. We also leverage Kaplan and Norton's Scorecards, to create Architecture Scorecards to roll the strategy themes and dashboard measures through architecture and implementation. Of course, that is a very terse overview of the early sections of our Enterprise Architecture Workshop, which explores and practices our Enterprise Architecture as Business Capabilities Architecture approach to enterprise architecting.

[5/8/08: There's a nice example of a Graphical History done by Dave Sibbet of Grove here (Evolution of the Internet) and another here (HBR Management Ideas and Practice). See also National Semiconductor's vision here and VizThink's Context Map here.]

5/6/08 Books For My Cart

Daniel Stroe pointed out these books:

• The Opposable Mind, Roger Martin

• The Power of the 2x2 Matrix, Alex Lowy and Phil Hood

The latter has come up a few times of late, so I really need to look into it. But this quote, highlighted by Daniel, from the overview of The Opposable Mind, has me interested:

"Martin shows how integrative thinkers are relentlessly diagnosing and synthesizing by asking probing questions—including “What are the causal relationships at work here?” and “What are the implied trade-offs?” Amazon editorial description

 

And I still need to look into this one:

• Prophet of Innovation: Joseph Schumpeter and Creative Destruction by Thomas K. McCraw

5/6/08 Scalability

These posts on Todd Hoff's High Scalability blog are great sources:

• Google Architecture

• Scaling Twitter

• Flikr Architecture

• Amazon Architecture

• YouTube Architecture

5/7/08 Del.icio.us

Scanning del.icio.us for a different sort on architecture topics, I got to wondering if this Trace showed up, and sure enough, a handful of folk have tagged it. Notably, Sam David tagged this JournalCurrent page this month, and Brad Arnst did so last month. Craig Cody, great guy that he is, tagged it some time ago. And Brian Sondergaard did too. Thanks guys! Craig blogs here, and Brian blogs here.

I'm always impressed when someone goes on record as having stopped by my site. You know, it deals with all that matters to actually, practically, getting things done with and through people. What technical person wants to be associated with that??? Oh yeah, architects who recognize that greatness is judged when systems are fielded and prove themselves successful! Successful: they have resolved all the tensions that arise in achieving great fit to context and fit to purpose, across all the contexts and all the purposes demanded of the system.

Actually, in truth, Brian didn't quite go on record... I just read between the letters and translated bsonderg to Brian Sondergaard. I expect Brian anticipates that anyone who keeps track of him would make the same leap...  I've referenced his blog several times in this Journal as well as the Bredemeyer Resources for Architects site. Brian does a really good job even if he's never pointed to this journal, but I wouldn't hold that against him. ;)  Anyway, Brian proves that my concerns are not just pink, for he often goes after the same topics that I do. He does have the Bredemeyer Resources for Architects site on his blog sidebar; I am grateful for that.

5/8/08: It did occur to me that Sam.David probably tagged this page before I added my leaky thoughts/flash floods warning sketch and I wonder if he would have tagged it as it appears today...??? I guess my next warning sketch will have to be "Warning: Self-Directed Satire At Play." But as sketches go, the two-headed archman being split asunder (repeated on the right) should make me famous, no? Inspired! Genius! Ok, ok, as I said, self-directed satire plays here. And as with all good satire, there is truth lurking beneath, and if a few lines ever spoke volumes, they are the lines in this sketch! Even if I say so myself. Well, nobody else is, so I get to, don't I? Somebody has to be kind to me... No? As for my "archman gingerly treading the tightrope of architecture"... Well, I think some things are best left unsaid. No that's not true at all; just unsaid by me--you can give me all the accolades you like! Oh, you never knew it was archman gingerly treading the architecture scope tightrope, the balancing act, the... dear, dear...

Well, did you at least get my apples and orange scope sketch?

And... did you notice I also have archwomen? See the platform heels (pictured right)? Oh, you thought they were databases. Well, yes, that too.  I expect you did at least see archwoman tightly coupled in the pile of bad code smells. 

Ok, so here's a test. Can you read the one below on the left? Yup, archwoman bound by bugs; and a reference to Gulliver's Travels, of course. Well, context may help... or not...

Am I reaching...? I've been playing this little game (with myself) to see how much of an idea I can convey with little black and white sketches drawn quickly in odd moments. The fact that I'm at all happy with the results only speaks to how low my expectations were of myself!! :-)  I realized that as a champion of visual architecting, I should provide a more visual trace; demonstrate the communicative power of a box and line sketch; that sort of thing. 

I have a few more sketches to scan in when I get around to it... but... only if someone asks very nicely. :) 
 

A snippet in the latest Fortune stood out. It was the advice the Pepsico CEO and Chairman Indra Nooyi's father gave her:

"From him I learned always to assume positive intent. ... When you assume negative intent, you're angry.  If you take away that anger and assume positive intent, you will be amazed. ..."

When a woman heads a global giant like PepsiCo, you just know she's been consciously finding the positive intent, reframing, all her career. Architects find themselves between a rock and a hard place a lot; too much. So you're perhaps better prepared to imagine what it is like to be a woman in technology or corporate leadership. I know there is a lot of really positive goodwill, for without that she would not be CEO (and you wouldn't be reading this). Indeed, there is so much goodwill, that even raising the subject as an issue may come as a surprise. But one has to look at the numbers (women CEOs in Fortune 500 companies, women in technology, women presidents, etc.; women still earn only 70c on the dollar, etc.) to see the effect of the (generally subtle) erosive pressure on outcomes for women. There is the constant extra work of having to exceed expectation, to establish and re-establish credibility and authority when you're a woman. And so Nooyi says "always ... assume positive intent." No matter what flack is flying around, don't be distracted from the deeper motives, the positive intent that lies beneath the emotive noise.

But... I don't know how positive intent relates to the preceding paragraphs, unless I subconsciously fear you won't have caught my irony and then you'd think I was being nauseatingly self-congratulatory; but really I was just having a little fun mostly at my own expense while gingerly trying to assess whether these "cartoons" are conveying the messages they encode...

I need to shepherd kids and pets to bed, so I won't type in more of the Indra Nooyi advice passage just now, but it is on page 74 of the May 12th issue of Fortune. Oh, shepherd reminds me--Charlie Alfred told me this great line he got from a friend of his at Anderson Consulting:

"architecting a product family is like herding bats; you know, like herding cats but in 3-D."

Now, that's a video I'd like to see. Go for it, Anderson! :-) That'd one-up the EDS herding cats video... Ah, the frontiers of competition... and another cartoon for me to draw... maybe... you know, if you ask nicely. Oh, alright, you can skip nicely; I'll take simply asking. No, no. Not even that. I have to remember "Talent does what it can, genius does what it must." With a quote like that, one can do all that one must, resting safely in the illusion of genius! So, I must, I must, I must do what I must. Get those kids to bed! Cheers.

Please remember my warning: Satire At Play

Or should that be: Slow Satire at Play

To which you'd respond: is that "slow satire" or "slow; satire at play"?

[For those outside the US: we have road signs here that say "Slow children at play." Slow children. Hmm. Must be mine. :-)]

So, how is it that only Sam David and Brad Arnst tagged my JournalCurrent page on del.icio.us in the past two months? Oh yeah, nobody wants to be called out for recognizing great humor, insightful lessons; well, artistic, literary, psychological, philosophical, economic and technical genius really.

Gotcha! ;-) 

What, you'd give me artistic, literary, psychological, philosophical, and even economic but that technical was just pushing it too far?

Slow satire. Definitely slow satire. With a twist of irony.

The joke's on me. And the joke's on the way we stereotype women. Why not support a woman in technology today? in leadership today? Raising consciousness has to start somewhere, and just how many women bloggers do you see on technical blogrolls or link lists? Is that because none are worth adding? I see. I think I should stop now.

... but before I go... I give you ... bats!

5/9/08 Cats, Bats and Vision Setting

We had herding cats (now starring archman) (product architecture vision setting)	Now we have herding bats (product family architecture vision setting)

The vision cartoon has to do with making the vision compelling to the various stakeholders. You can see how much more challenging it is in the product line/family case! Like, now I have to learn to draw bats! 

Well, once again: I must, I must, do what I must: get those kids off to bed! I think tomorrow night I'm going to watch a movie! Save the world. Something. Not this!

5/13/08 Architecting Across

In our first software architecture workshops at HP, I used a triumphal arch as the central visual element for a graphic template for a warm-up team exercise on what architecture is (the arch), inputs and outputs (the roads), success factors (the pillars), the challenges (past/behind and future/foreground), etc., of architecting. The exercise was dropped, but the arc and arch in architecture (and overarching concerns) has stayed with us, as a central thematic element in our conversations and points about scope. So, you'll see the arc in my "cartoons" as well as in our "umbrella diagrams" and we use it to mean architecting across: architecting across scopes (components of a product; products in a product family; components of a solution; etc.), across disciplines in EA (business, information, application solutions, infrastructure), across concerns (user experience and system behavior and system structure). The arc represents the tradeoff space, and obviously this is multi-dimensional. The sketches aren't meant to be complete, only illustrative of some key dimensions of scope.     

Architect across the product family	Architect across the product family (low to high end kiviats)

So, architecture serves system qualities, and architecture serves behavior:

The last is my visualization of Dan Pritchett's comment that we only have so much rope to fit around our spider diagram (also known as a kiviat diagram), so we have to pick carefully which dimensions we optimize. This is what we mean by the circle of excellence for the product. Anyway, the neat serendipity is that it looks like archman is steering a ship with the kiviat. Isn't that cool?

P.S. Here's a fun little demonstration that not everyone gets the notion that scope and context matter (in particular, within the scope of a software architecture site, architecture means software architecture).

5/13/08 Architecture Viewpoints

In Achieving 20/20 Vision Through Architecture Viewpoints, Jeff Ryan notes:

"Quality attributes, which express the desired non functional qualities of the system, are used to capture the non functional requirements. The questions quality attributes answer includes:

• How many users will be logged on to the system?

• How many transactions will be performed in a given time period?

• What is the expected response time?

• What are the hours of operation?

• How frequently will changes be needed to the system?

• How sensitive is the system to security breaches?"

5/13/08 Business Intelligence (Adapting the Knowledge Pyramid)

I'm very interested in business intelligence (and agents/Agent Architectures, events/EDA, etc.), and I just wanted to keep track of a sketch I drew (prompted by Dave Sibbet's Knowledge Pyramid).

If I'm going to keep doing this, I'm really going to have to work on my handwriting! 

5/15/08 PPOOA Visio Add On

FYI:

"Our PPOOA_Visio CASE tool offers a new module ("Visio add on") that translates the PPOOA_UML architecture diagrams of a system to a XML file that can be read by Cheddar, a free  "scheduling analyzer and simulation tool" developed by the University of Brest (France)--see http://beru.univ-brest.fr/~singhoff/cheddar/.

When a software architect has completed the software architecture models in PPOOA_Visio, he or she can execute the PPOOA _XML add on. This add on performs the identification of the different components of the system architecture ( processes, buffers and resources) and the dependencies among them. This information is described in an XML file that is used as an input to the Cheddar tool. The Cheddar tool offers real-time feasibility checks based on sheduling theory ( for example Rate Monotonic Analysis, RMA) without executing a  real scheduler. Additionally Cheddar offers simulation engine which allows the software architect to describe and run simulations of the architected system. You can see a video demo at http://www.ppooa.com.es/ppooa.htm"

Jose L. Fernandez
PPOOA team leader
 

5/15/08 Ciao

 

 

 

Ciao :-)

 

 

 

 

 

 

 

 

Oh, don't worry; it's not that you didn't ask for more pictures! I'm off to London...

 

So, how do you like my dandy exit shot? Macro is fun--it reveals a whole other fascinating and surreal world around us!

 

 

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.

 

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.