A Trace in the Sand
Online Architecture Journal
by Ruth Malan

I also write at:

- Resources for Architects

- Architecture Action Guide

- Trace In the Sand Blog
 

HelpMatch:

- HelpMatch Wiki

- HelpMatch Google Group

 

Other Interests

Trace in the Sand
Architecture Journal

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

2011

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- Current

2010

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December

2009

- January

- February
- March

- April

- May

- June

- July

- August

- September

- October

- November
- December

2008
- January
- February
- March
- April

- May
- June
- July
-
August
-
September
- October
-
November
- December

2007
-
January

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

- September
- October
- November

- December

2006
-
February
- March

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

- October
- November
- December

Topics
- Press to code
- Iterative and Incremental
- Randy Pausch The Last Lecture
- Strategy Models
- Books
- Del.icio.us
- Cats, Bats and Vision Setting
- Architecting Across
- Architecture Viewpoints
- Business Intelligence
- PPOOA
- Ciao
 










 

 

 

 

 

 


 

 

May 2008

5/1/08 Golden Carrots

Signing up on our architects email list today, Mark G. from the UK said of the Resources for Architects website:

"fantastic site"

It made my day! Two words. But that spontaneous and appreciative two word-er stands out in the landscape of my weeks and months as a highlight. Naturally, I take all the signups on our mailing list as a huge compliment—by implication a signup expresses appreciation and interest in what we do. Personal contact information is a treasure, and freely, voluntarily, giving it to us is an honor that I don't take lightly. But going that extra step and saying something like "fantastic" shows that Mark understands that explicit recognition is powerful in a world where we typically expect that implicit recognition is good enough.   

If you're just tuning in: this Trace is a very different space than the Bredemeyer Resources for Architects website. This is the time-ordered trail of some of my thinking; given that customers own a lot of my thinking, Leaky thoughts warningI'm not free to reveal those client-specific thought trails here. Although I reserve the right to edit this journal freely, it is a less edited, less organized space than the Resources for Architects site. In other words, my purpose here is not to demonstrate minimalism or user-centered design! My purpose is simply to shape my own thinking and keep track of places I explore. I make this spot available on the I-way in case it is useful or interesting to architects as they try to bring a principled approach to "right systems built right" to their business; but I fully recognize that it won't suit the tastes of everyone, nor even many.

But before I sell myself too short, what I am about is setting a vision for and facilitating a change in our software field. A change that embraces architecture as the path to excellence in systems—the kind of excellence that is in the fit of system to context and to purpose, a fit so compelling it creates delight. Change is led, and rhetoric, the art of persuasion, is an important instrument of leadership. So, I try to lead, and I try to demonstrate leadership. And this journal is an avenue to exploring the topics and finding the voice that will help me in this mission I've set myself. The dual to this, is that if you don't feel both inspired and in some way enabled by what I write, then I've failed. I've failed you, and I've failed myself.

5/1/08 Press to Code, or Not to Press

It can be just as well to remember that the real "requirements" are much softer than the requirements our stakeholders express, since they're generally being asked for desired state, not bottom-line acceptability. Even with respect to the bottom line, when push comes to shove, users will more often than not happily take good enough over none at all, and good enough typically has a surprisingly low threshold. Yes, we'll face competitive heat with a product that underperforms relative to the competition's product, but even an inferior solution can buy time that we don't get with no product at all!

This is not an excuse not to do architecture. This is not an excuse to push aside "right product built right." This is about finding a way to move forward when the urge to reach illusive perfection is a sticking point for a project. The broader the scope of the effort, the more ambitious, the more tensions have to be balanced and the more tradeoffs that have to be made, the greater the tendency to become mired in finding a solution that works well for everyone.

No code: failure.
No architecture
: failure.

Architecting across variants in product familyI worked with a next generation product platform architecture team that had a lot of alignment and buy-in from three of the four product groups, but the fourth had quite a different customer environment and a very different internal development culture. I counseled that they leave the fourth product out of the platform effort. It had not been part of previous generations of the platform, but now the R&D management team wanted to bring it into line with the platform effort, in part because the hardware platform that all four products relied on was changing and it created an opportunity, they reasoned, to bring the four products into unity on a common software platform (meaning shared infrastructure services and common components). It seemed like a compelling case, but I could see that they had to fire the people involved on the fourth product, doom the entire platform effort, or continue to support three products on the platform and let the fourth run fast and loose. Obviously the first was not going to happen; it wasn't even a good solution! When you try to spread the scope of an architecture effort too wide, the tradeoffs for the good of the whole, or in the platform case, for the good of the many, impose increasingly high costs on the outliers. So you have to pick off a doable piece, and narrowing the scope so that requirements can be agreed on without miring the whole effort in unbounded uncertainty, endless turf wars and political shenanigans, is a pragmatic approach.

The art is always in the staging, and being aware of the stretch points where the architecture is going to have to be most flexible. Architecture is very much about lowering the cost of change, about positioning the system to evolve—at least to add functionality and to scale operationally.

Archman walks tightrope of architecture scopeThe key is to identify the dominant uncertainties, the dominant complexities, the dominant risks, and to put in place strategies for addressing these that the development community can align their passion and ingenuity behind. We have to figure out what is make-or-break, and focus our energies there. That very effectively Paretos our attention, gets us that 80% of the way there for 20% of the effort. On the make side, we have to know what the heart of the compelling value proposition is, what will bring that element of delight that will cause the customer to happily accept all the areas of good enough—and even put up with less than good enough in some areas, at least for a while. I ask platform teams to look for the difference that makes the difference, both in terms of the user goals/experience and from the perspective of the development team—what is compelling in value terms that we cannot compromise, and what is structurally significant, that we cannot compromise. For if we fail on these points, we lose the tradeoff battle before it even gets going. This recognizes that there are lots of differences across products in a product line/family, but not all are going to be architecturally significant, not all will be the difference between success and project stall-out.

As the years go by I'm realizing that my style of helping people to find the right answer themselves, by asking them the questions that lead them to discover their own right answers, is not always the most effective approach. This is a world in which dominance styles co-exist with networked, collaborative styles, and sometimes to be effective I have to move more towards the dominance style. In short, I have to do more didactic telling in situations where that is the norm, or where it is the most expedient approach. That is very uncomfortable for me. And I sense the same is true for many architects. We have to work so much through persuade and influence, through facilitative leadership, that when we need to shift to forceful assertiveness it feels unnatural and strained to us. But just as our architectures have to flex, so do we.

Sometimes we have to be forceful in insisting we give due time and attention to requirements and architecture; due time, not undue time. And sometimes we have to be forceful in insisting we retrench from initial mandates, right-size the scope for a successful next release and get into incremental development post haste. It can be very hard to find the balance between these positions, Archman rent assunder by competing prioiritiesbut if we don't, our business will likely perceive failure and develop potent architecture anti-bodies and overcorrect in the direction of expunging architecture over the next few years until the legacy of kludginess raises its own antibodies, the heralders of kludginess are themselves expunged, and architecture is ushered back in. Architects have to find the balance in so many dimensions, but this is a critical one!

Big bang, broad scope: too much time on design and no code. Failure.

Leads to fear of design: no architecture. Failure.

Many in the software field have been so burned by these (over?) ambitious projects and their extreme spring-back to retrenched positions that expunge architecture, that there is this cautious pussy-footing around architecture leaving the strong impression that code is the holy grail and all else is worth naught. I strongly reject pandering to the anti-modeling/anti-architecture constituency. The answer is not all or nothing. The answer lies in agile architecture and agile development, with cross-functional teams and overlaps in what work gets done when, so that we can foresee and mitigate the downstream effects of decisions made along the way. For if the decision is to jump right to code as our tool for thinking about the system and discovering requirements, we have to recognize that all the learning that needs must happen, is now happening in a much more expensive vehicle; one which we are much more loathe to change; much more apt to accept and push forward. We will accept the compromised solution under the promise of evolving it to a more simple, more clean and predictable one, but we don't. We let things slip and slip until a huge correction is needed, but huge corrections are risky and slow and businesses have low tolerance for either of those qualities, so we get back into rush mode and create another round of kludgy barely-good-enough responses that leave the business mired spending 80% of the technology budget on maintenance, and so the vicious cycle goes. And grows.

"The greatest danger for most of us is not that our aim is too high and we miss it, but that it is too low and we reach it." Michelangelo

Not to compromise on excellence, but to figure out what excellence means for the set of goals, concerns and constraints we have to balance.

"The main thing is to keep the main thing the main thing." Steven Covey

Excellence takes aspiration, and perspiration:

“I find that the harder I work, the more luck I seem to have.” Thomas JeffersonHammering the future into shape

Yep, that hard work with a hammer:

"You know I used to think the future was solid or fixed, something you inherited like an old building that you move into when the previous generation moves out or gets chased out.

But it's not. The future is not fixed, it's fluid. You can build your own building, or hut or condo, whatever; this is the metaphor part of the speech by the way.

But my point is that the world is more malleable than you think and it's waiting for you to hammer it into shape."

Bono, "Because We Can, We Must," Commencement Address by Bono, May 17, 2004.

And words; I'm reading a collection of essays and speeches by Martin Luther King. In an early speech, he wrote about being the best at what you do--the best street sweeper, the best engineer. It strikes me that great rhetoric should be required reading for architects reaching to be great. We have to learn how to lead, how to inspire. And how to act. Back to the hammer. And the chisel.

5/2/08 Self-Actualizing

It was very nice of Grady Booch to put his Life Of Ands talk (April 25 post) on his website. Of course, enough is never enough, and I sure would appreciate a .pdf version...

Anyway, this quote from Grady's 4/25/08 entry fits perfectly with the self-actualizing theme:

"The good life is one where you develop your strength, realize your potential, and become what it is in your nature to become." Aristotle

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. Mismanagement which, unfortunately, is all too common. Though projects start with the best intentions to do the learn/improve piece that is implied by iterative, they may (be asked to) give up on those intentions under schedule pressure.

What we aim to do is multi-facetedlearn/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.   

Iterating in the Visual Architecting ProcessWhen 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 (V) 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 Architecture activities overlap with concept/requirements and constructionwhat 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-gojust loosening up the "code" requirement early on, to allow for cheaper/more flexible/adaptable learning via models in the early cycles.Architect across user experience and system structure 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:Competitive landscape map enhances group collaboration

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

5/6/08 Scalability

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

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.

Architect across fit to purpose and fit to contextI'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. Architect torn between conflicting prioritiesHe 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... Architect humor: Archwomen horrified at tight coupling and bad code smells

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 the coupling in the pile of bad code smells

Ok, so here's a test. Can you read the one below on the left? Yup, archwoman Archman bound by bugs: allusion to Gulliver's Travelsbound 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. ..."

Archman between a rock and a hard placeWhen 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.Slow satire at play

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. :-)]Archman 'Tude

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

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

Archman herding cats. Archman herding bats: like herding cats, but in 3d.
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 AcrossArchitect across user experience and system structure

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 structure and behavior

Architect across the interfaces

Architect across the product family. Architect across the product family from low end to high end.

Architect across the product family

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

Archman walks the architecture scope tightrope.

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

Archman balances structure and behavior

Archman: only so much rope to fit around the system kiviat.

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).Business Intelligence and 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
Dandy exit shot
 

5/15/08 Ciao

 

 

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!

 

 

Road ends in water.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.

Copyright © 2008 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: May 1, 2008
Last Modified: December 01, 2011