A Trace in the Sand
Online Architecture Journal by Ruth Malan
I also write at:
Trace in the
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:
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, I'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.
I 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.
The 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, but 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 Jefferson
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.
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
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-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 (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 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!
"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:
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:
These posts on Todd Hoff's High Scalability blog are great sources:
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 the coupling in the pile of bad code smells.
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.
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
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.
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:
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
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
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!