A Trace in the Sand
by Ruth Malan
September 201009/01/10 Your Co-ordinates
This journal contains notes I take as I explore what it takes to be a great software, systems and enterprise architect. This may be an architectural consideration like architectural element design (identifying responsibilities, separation of concerns, coupling and cohesion, cross-cutting concerns, etc.), some aspect of the architecting process (like iteration, refactoring and documenting decisions, where requirements come from and why it matters to the architect, visualization and design intent, and visualization and design reflection), or it may be a characteristic or skill that is useful to develop (like visual modeling, humor or influence and persuasion).
Just so this journal isn't too empty while we wait for September entries to amass, please forgive my stepping out of character long enough to "promote" some upcoming workshops:9/1/10 Upcoming Software Architecture Workshops
There are still seats open in the Software Architecture Workshop to be taught by Dana Bredemeyer (in English) in Düsseldorf, Germany, on September 13-16, 2010 (hosted by CodeCentric). The workshop in The Netherlands in early October is full and wait listed.
The next Software Architecture Workshop in the US will be held in Boston, MA on November 8-11, 2010 (enroll by September 10 to qualify for the early enrollment discount).
You can think of this as learning how to design architecture and in the process constructing a visually rich narrative for your system so that you fully empower the development team (throughout the evolution of the system) to create (and evolve) a system that meets business and customer needs -- a system that stands up to the push and pull of business demands and the need for design excellence (where it matters, and satisfices otherwise). Iterative. Incremental. Evolutionary. Participatory (without being overwhelmingly so) and concurrent.
9/2/10 A Shout!
I looked in on the SATURN blog, and saw that Mary, bless her, linked to this journal yesterday. Four and a half years into journaling here, and it gets its first "full of great ideas" shout! This is early in the month, so if you want to validate Mary's assessment for yourself, these are the (surviving) posts from August. Naturally, all the good ideas are by reference, not mine at all. :-) And, while you wait for entries, perhaps this is a good time to read The Art of Change: Fractal and Emergent. Facing shrinking budgets, we have to be more vigorous and diligent about the goodness and rightness (value contribution) of what we do. We can be conservative and retrench. Or we can look energetically for the opportunities there are, and make them successful. This is exactly the time to to be sure that the technical work we lead is not just great, but focused on the right (in business impact terms) problems! 9/2/10 In KindLet me return the favor. New from the SEI:
This, also from the SEI, looks very interesting:
9/2/10 Software Visualization
I just came across UbiGraph. I've looked at some of the demos, and it looks exciting.
9/2/10 Push Back (or design is a matter of guts -- the guts to say it's not just about the guts!)
But, on second thought, it is perhaps more sensible not to have the guts to say that... ;-) Ok, a simple example to make the point. Alongside is a portion of a receipt from a well-known retailer (dated 8/5/10). Notice anything? Now, exactly who does allocating a proportion of each rewards coupon against each item serve? Why does a 13 item receipt have to be exploded from a (13*2) + 4 line receipt into a 13 *(2+4) line receipt? One that is very hard to follow, at that? [I cut it off there to protect the innocent, but the remaining 9 items were not "eco-friendly flora."] What customer is going to be impressed by a two foot long receipt for 13 items? (Two feet, I kid you not!) The impression of waste so absurd a receipt conveys, isn't make-or-break but it does flavor the experience. A product coupon may reasonably be allocated against that product. Generalizing that to spreading other kinds of coupons across all products rather than applying them against the sub-total was a judgment call someone made. Seriously!
So who thinks requirements are just there to be written up? This is obvious. We know this. Yet we shove it under the rug for convenience. So I'll say it again for emphasis: "Requirements" are interpretations and interpolations across customers and other stakeholders. They are, in short, for the most part best guesses. Yes, well-intentioned best guesses. But the point is they are not immutable! At least, not until the process casts them that way.
Challenging systems are, well, challenging. And challenges are introduced by the requirements (and constraints, which we could view as non-negotiable requirements). This is a trivial example (and not architecturally significant unless there's a persistent neglect of customer experience; though leading a culture of permitting questioning is, arguably, architecturally significant). Still, it makes the point, doesn't it? We invent requirements. Even pretty simple things like applying a coupon is subject to alternative approaches, and someone makes a judgment call. Some of these might just make the system look silly some of the time. While others really matter quite substantially to the complexity and cost and value of the system. Don't we want the person with responsibility for system integrity, the person with experience in what it will take to build the system, to be involved in saying which judgment calls he or she should make or at least get to influence?
Btw, online receipts from the same company simply place the coupons at the end, after the subtotal. A competitor's cart shows coupon allocations to items along with price after coupon in the cart, but not on the receipt. etc. Lots of small variances. Judgment calls! You as the architect by no means want to make all of them!! But the judgment call as to which judgment calls you ought to make, should be yours -- if you are to be held to account for system integrity!
Yes, it is important to stabilize requirements! So we want our process to quickly shake out stupid ones, to hone in on a good guess at what will make the system successful, and then be prepared to learn, adapt and evolve the system (and the "requirements" we build to). But... In this economic landscape, more managers are looking for software heroes who can rescue projects with great technical feats. These "software ninjas" have always had, and no doubt will continue to have, a strong place in our software culture because they get things done, and what we actually build has a way of shaping expectation and reality, so the successes are self-fulfilling and self-reinforcing. And while failures may burst through our attention screens every now and then, generally we don't hear about them because, well, they're failures! Google Wave made a Google-sized splash, but most failed systems die quietly, adding to the failure stats but otherwise unattended except for the bereft "immediate family."
At the same time, architects who simply want to deal with technical design challenges are more confident that that is the place to make their contribution. Besides, if we didn't have a personal preference for the technical, we wouldn't be in this field, and the fuzzy front end is highly ambiguous and reliant on interpersonal skill. Moreover, in tough economic times, we only want to do the highest priority, most crucial, most sure-win things. So of course these are totally obvious, and we don't need to waste critical resources on messy prototyping, ideating playful nonsense creativity stuff; besides, that'd only give off a project odor signaling we don't know what we're doing. Right? I mean, can anyone fault managers if they only take on burning bridges and impossible-to-miss targets like cloning what the competition is doing? Or fault architects for retreating to the safety of designing to spec -- it allows for efficiency of focus which is crucial in lean times, not to mention necessary given how tough the challenges are.
It takes guts to act boldly in hard times. And yet, how else can one act? If I'm going to lead a development team, I want to be sure I do what is reasonable to do to make them successful. Easy/immediately obvious and right are orthogonal--they bear no necessary relation to one another. If easy and obvious is good and right, great! But I'm going to be wary of easy and obvious, and look for the bigger opportunity and better solution hiding behind the wings of the obvious. The jewel of creativity is protected by the dragons of chaos, and we need to face those dragons if we want to compete through innovative distinctive value.
Rah rah rhetoric. I'm sick of me too. The people who get it, get it already--in fact, they taught me! So. What. Ok, back to visualizing code with me. Sorry, I had to vent that top-of-stack reaction. Totally predictable really. But it was fun. Didn't you like that dragon thing? Totally quotable. In innovation circles. What the chocolate am I doing dangling it in front of architects though? [Chocolate? Well, if I'm going to have you pull up on the reigns in surprise, I'd rather it be at chocolate than some profanity. :-) ]
Uh, but first... let me be clear. The way I see it, you decide what is architecturally significant and what rocks to push (up- or downhill) in your context. VAP says you at least need to assess which requirements are architecturally significant and understand those, and you need to ascertain uncertainty, challenge and risk and create strategies for addressing those that are make-or-break. That said, if you are involved in the conversations that shape the architecturally significant requirements, I'm confident that you will be able to do a better job of technical design because you'll have richer insight into tradeoffs you're making.
Tradeoffs are at the heart of architecting. On what basis are alternatives chosen? Stated requirements. Ye-es. Aren't you just a little uncomfortable at that? Ok, ballpark estimates, so we know what we're shooting for in terms of the design envelope. You're responsible for system integrity--ok, we'll even scope that down to structural integrity. And you're confident that someone's ballpark estimates for scale requirements 6 months after deployment are reasonable? On what basis? Exactly! You're involved in requirements! No-one else is thinking 6 months after deployment! They're happy with YAGNI. But you know that you're going to be hit by the blame bus if the whole shebang blows up right when the business looks like it is a run-away success! Besides, when you participate (just enough) in requirements exploration, you contribute insight into new opportunities technology makes possible, and what it will take, and the strategy and requirements will be better for your involvement.
That is not the same thing as saying you take over the turf of the strategist or business analyst. They have a crucial, valuable role to play. You bring knowledge of where technology is going, extant system and team capabilities, etc., and another perspective and ideation capability into the discovery process. For their part, business analysts bring customer understanding and the bandwidth to do further, deeper requirements exploration. You bring "what it will take" knowledge to the convergence and scoping decision process. Etc. Circles of innovation stuff. Collaborative and concurrent--meaning, because you're involved, you can start to explore the architecture concurrently with the requirements exploration, and one informs the other. Better outcomes. Sooner. (Caveat: unless overdone. Process, like mammals, shouldn't be overcooked. Nor undercooked. In case of worms and bugs.)
In system design, we want crisp, clear boundaries separating areas of cohesive responsibility. Yeah. But however we slice and dice responsibilities, we're going to knock up against cross-cutting concerns. Organizational design is system design, with its own (morphing) set of wicked problems. We can attempt to simplify the problem by separating roles and assigning chunks of the process to them. Neat. Clean. Not. Wicked problems don't chunk cleanly.
Between Getting Past ‘But’ and The Art of Change: Fractal and Emergent, we have two patterns for innovative, agile organizations -- the Fractal and Tandem Pattern, and the Circles of Innovation Pattern. Ugh. It had to happen. I had to end up casting those as patterns, but now you get how they're important, right? ;-) The utility of framing!
These are tough times. Depressed economies make for many depressed organizational psyches. Lean can be mean in contracting economic contexts. Doing the essential, and not stepping on toes is safe. And yet, playing it safe is no longer safe either. You have to figure out where to be bold, and where to retrench to conservative plays. Matching the competition in a shrinking market is tough cut-throat stuff. If you can find a way to differentiate through compelling value, you shift the odds.
Leadership is not so much a matter of courage per se. It is a matter of being inspired, driven, passionate about something compelling that once seen simply must be done! That breeds courage even in a shy introvert like me! A recession, double-dip and all that, has a double-edge. Contraction (with all of its "lean initiatives") and risk-aversion. And the need to do something so that the hurt doesn't strike close to home. The need to out-innovate and out-delight competitors is even stronger than it ever was! And we have to do it with less resources. That calls for all the initiative and creativity we can muster.
I personally don't see how architects can disengage and retrench to safe technical turf! The need to come up with and build the most compelling value propositions and do so quickly is just too great. That is very technical, but strategically so. It can't be strategic unless informed by an understanding of what it will take to delight, where it matters, and satisfice otherwise. Our brilliant technical problem solving has to be applied to solving the right problem! It is not enough to be able to read the requirements because the requirements leave out all the conversations and guesswork where options were swept from the table; one has to be able to read between the lines with enough intuition to know where the subtext has to be probed, to know when the "undiscussables" have to enter the conversation or they'll derail the effort, to know when thinking just enough about where the system is headed is important to structural design. E. T. C.
There is no one "right problem." And the architect has no particular magic with which to cast the "right problem" -- at least, not alone. Ah yes, the circles of innovation pattern (impish smile). Well, that was fun. What, you hated it? Oops. Uh, you'd rather hear what we're thinking and learning about software visualization? Oh.
I updated my Trace In The Sand Blog site.
It's only the first moments of its rebirth, but I think the direction is
I created a SmileServer blog which will mainly be an architecturally-relevant smile-teasing
(charming/humor/quizzical/etc.) linksblog, though I don't rule out the
possibility that I may on occasion be brash enough to post one of my own
attempts at drawing a smile. And I may even get around to another post to my
Trace in the Sand blog, now that I have reactivated it -- it required some tlc
after being crippled by spam.
9/5/10 Design is Design
9/5/10 Design is Design
Sara pointed me to AdvancedFictionWriting.com. Hold on -- this is about architecture, by a software architect. Randy Ingermanson applies his software architecting process to writing fiction. What's more, it is fractal!
Jeff Atwood has noted that none of us is as stupid as all of us. Dilbert's PHB won't stand firm on whether some of us is smarter than one. David Perkins, in King Arthur's Round Table: How Collaborative Conversations Create Smart Organizations, presents a balanced perspective. Here's a snippet from the book:
Collaboration isn't "decision making by committee." It is the effective use of team time and of individual time. Model out loud and in pairs/groups can produce breakthoughs in thinking (and motivation -- simply put, it is fun!) not achievable alone. New connections are made. Assumptions that would tend to lie dormant and implicit are questioned and drawn out. Etc. That said, concentrated individual work time is important too.
But the hurly burly of multiple perspectives can seem chaotic. Chaos and dragons are intimate. I know. I've been fighting off a few chaos dragons myself. So far, they're winning. Just kidding! Goodness, optimism/enthusiasm and persistence have some bearing.
9/5/10 The Paradox of Choice
I just heard Sara say: "This is 20-10 dude. We have water bottles."
Indeed. Themos stainless steel water bottles that fit in cup holders and which will keep water with ice icy for hours in blazing sun. Of course, these are superb for Hobie kayaks which have -- hold on to something -- cup/bottle holders! This is the age of choice explosion. We have so many choices, we can be paralyzed by them.
In the fuzzy front end of design, some people are just made antsy by the ambiguity and lack of direction that comes of searching the possibility space. On the other extreme, there's going too far with the search. Balance is key. We diverge and converge. Each time we converge, we're narrowing the options space.
The thing is, we need to design to breach the pack, to create an identity space that makes the customer's choice, and then use model, easy. To punt on choice design, is to leave system destiny entirely to "Darwinian evolution" through market selection, rather than speeding that up with enough design experimentation to close in on a better entry point for market feedback (and selection) to improve upon.
Great design isn't generally, repeatedly, something we simply stumble into right off, nor the result of a random walk, for tweak-tweaking on the base of what has been done, is constrained by a growing set of expectations and uses that embed the emerging design in quickly mounting inertial forces. Design is intentional, including the envisioning and scanning process that seeks out and clarifies the design concept.
9/6/10 The Little Engine That Could
The first book that Ryan saved up for and bought (when he was three or so) was a version of The Little Engine that Could that came with a little wind-up engine that climbed the pages. It was something like $18 and there was no way I was buying that marketing stint, but he wanted it badly and negotiated chores he could do and saved for it. So we took our little blonde curly haired angel with his bag full of earned and saved coins latish the evening that he reached the purchase price. He metamorphosed the salesperson from crabby to utterly charmed with his twinkling excitement and pride, and she patiently counted out his coins.
The Cutter editor asked me if I could make the deadline they've set for Part Two. I replied "I think I can, I think I can, I think I can..." and that memory flooded back!
The importance of positive thinking, and of the doing that is part of making it meaningful and self-reinforcing...
9/7/10: Of course, life also has its unwinnable battles. Our cat of "handsome older gentleman" fame died this evening. His last days were very hard and sad as he got weaker and weaker. This was the cat that elicited Sara's first real word (by which I mean the first word that wasn't a variation on the babbling sounds babies make like mamamamama that more easily becomes mama) when she was 9 months old. He was a substantial "personality" who wove himself into our lives and love.
I used his picture (left) when I quoted this bumper sticker (last October):
Each of us is UNIQUE
Just like everyone else
Escher's Eye is profound -- we view life differently because we are mortal. And it is hard! Harder still when the struggle with mortality is before us -- as it was before me in a little creature that meowed a hello whenever I came to lie with his little body with its life ebbing away.
9/8/10 Dean Thompson!
One of the software architects who shaped my thinking about architecture was Dean Thompson. Today I discovered he is now a full time artist. Well, he always was an artist, he just used to apply his artistry to system design. And now he applies his geek side to his art. This is Dean's statement about his art:
"We live our lives surrounded by the infrastructure of our society. Still, most of us never see it, or perhaps more properly never really look at it. I am fascinated by the shapes and textures of this unseen landscape of technology. These enormous machines make our lives possible and yet the details of their functions often remain a mystery. Their metal and concrete geometries seemingly epitomize the domination and control of our environment but they exist along side of, and are juxtaposed with, elements of the organic world that can never be totally pushed aside."
9/9/10 Gravity Rules
Dana pointed out a bumper sticker to Sara. It said:
She's the kind of kid that needs to be reminded of that.
9/9/10 Booch: Stay Tuned
Today I was googling for a Booch quote -- at least, I think it is something I ought to ascribe to Grady, so I wanted to make sure. Anyway, I came across this interview with Grady Booch reflecting on systems-of-systems, and his early experiences in embedded systems -- interesting stories and perspective. As young as it is, our field has interesting history!
And I came across this:
Well, that's exciting! A mystery and a thriller!
Richard Morris's Geek of the Week interview series looks interesting. I read his interview with Roy Fielding (of course!) and look forward to going back to read more of them.
9/9/10 Call for Papers
"We invite you to submit a paper/abstract to The 15th World Multi-Conference on Systemics, Cybernetics and Informatics: WMSCI 2011, to be held in Orlando, Florida, USA, on July 19th - July 22nd, 2011 (www.2011iiisconferences.org/wmsci)
Below are the next deadlines for WMSCI 2011 (Check the web site for possible extensions or new set of deadlines):
Papers/Abstracts Submission and Invited Session Proposals: October 6th, 2010 Authors Notifications: November 29th, 2010 Camera-ready, full papers: February 28th, 2011"
-- email from wmsci, 9/9/10
Rain at last!
And a phd comic just for me: Enthusiasm is highly contagious!
We wouldn't want to get any of that on us, now would we? ;-)
9/13/10 Close To Home
Yes, I advocate sketching and diagramming by hand. It is an important tool to have in our thinking, communicating, collaborating toolkit. And so is our UML tool of choice. And various software visualization tools too. We just tend to get so carried away by "technology" that we forget how important the hand is to seeing and showing, and so mine is a soft voice in the technology landscape reminding us that the pencil and colored markers (and the eraser/recycling bin) are mighty fine tools for software architects, and we ought to use them (more/at all/etc.).
A voice from outside the TV-culture mainstream:
"This form of voyeurism is cannibalizing someone's misfortune," says one of the great singers of her generation, who owns neither a television set nor, it can be reasoned, the latest issue of US Weekly. "It's a way of dehumanizing someone. We are all just fragile, flawed individuals."
-- Natalie Merchant, responding to a question about Lindsay Lohan as quoted in The Natalie Merchant Interview, August 18, 2010
Aside: Someone mentioned Lindsay Lohan to me in July when I was on stand-by for jury duty, and I had to Google Lohan because I had no idea who that was! Were it not for that chance reference, I wouldn't have had any context for understanding Natalie Merchant's reaction!
9/16/10 Made My Day!
This comment (in an email to Dana) made my day:
"Thanks for your software architecture site. Wow, what a resource."
-- Douglass, personal email to Dana Bredemeyer, 9/16/10
"I am very impressed with the quality of information provided in this site. Its a good resource for existing as well as future Architects."
-- Aftab, mailing list sign-up, 9/16/10
Oh, don't worry -- I won't become all unmotivated just because two people were nice!
I've been spending all spare cycles fulfilling my role as Dana's primary stress elevation program! Once I'd navigated my way toward a meaningful unifying aesthetic theme, the "Making It Visual" presentation flowed nicely. Finding my way to that point, well, just required more incubation time than was entirely comfortable for all concerned. The result is in the category of "if you like this sort of thing, you'll find this the sort of thing you like"... What sort of thing? I think the points the presentation makes are central, important, and uniquely nuanced, and it was fun using some wonderful art to lead into the various insights and pragmatic guidance.
The person who has zero tolerance for representation and interpretation, metaphor and layers of insight will no doubt be impatient with the presentation, but they won't learn how to create rich systems that imitate organic growth and evolution, or succeed along any other such analogical paradigm. With another week or two of evenings and stolen moments, I think it could become something really quite splendid. Oh well. Such as it is, I'll put it, or part of it, on slideshare some time. Maybe. If someone asks nicely! ;-) But now I have to get back to Part Two of the Cutter Report. (My family groans! Sara told me the other night "we need a spare mommy.")
Btw, I used Escher's Eye. What points would I want to make with that? That's your homework assignment. ;-)
So much of what architects do, goes unappreciated because it is facilitative of the good work of others. It creates context and culture, shapes and guides. But without dictating and exerting forceful territorial claims because those just alienate when what is needed to create great systems with and through others is generative collaboration. And we coach architects, so we're even further back in the acknowledgment/appreciation food chain. So the kind words here and there expressing (even with the parsimony so characteristic of our field) a sense of appreciation, are (in the proportion reflected by the ratio of the passionate work applied to the kind words that come my way) important and meaningful to me. So, please bear that in mind when I quote these "carrots."
Well, I think a keynote should inspire, help us know what we know by providing mental models that organize and shape our thinking, and lead thought so we do better moving forward into a future where we want technology to enhance what people do, achieve and aspire to. That is a tall order! But it is a tall order for the presenter and the audience. Inspiration isn't simply poured into passive molds; it can be invited, one can allow a presenter to lead us to new insights and formulations that interact with how we think and see things, allowing the presenter to create a crucible for inspiration. But inspiration cannot be dictated.
The "Making It Visual" presentation is one of those things where attitude and orientation impact what one gets out of it. The core messages are absolutely simple, cornerstone pragmatics -- the kind of thing any warm-blooded architect should thrill to, for they are the boiled down crucial essence of architecting. And these are layered with insight and beauty (that is, beauty in the references it draws in) that make it as rich as the internal-lights-brightly-lit perceiver is willing to make it. In other words, it is entirely dismissible or entirely embraceable. And not much in between. So, I was very heartened when Dana copied me this message that he got after his presentation this morning:
"I was impressed by your speech!"
Way to go Dana! He took my slideset as a launching point and created his own distinctive narrative, and managed to have fun delivering it! That, on its own, is impressive! Doing it with only one night is truly astonishing! Well, we ran with it (literally) and talked about it a bunch while it was "in incubation," and I also did give Dana drafts before yesterday so as we iterated on it his input was integrated, but still he only got the final draft after he finished the workshop -- i.e., late afternoon yesterday.
If you think architecting starts and stops at deciding whether to go with Spring or Seam, then... the presentation probably falls in the "eh" category.
Oh well, when I get a moment maybe I'll try to draw enough energy back into it to write up my view of the narrative (I've done this for the first half, but need to still get to the second half) and put the slides on Slideshare and the speaker notes on the Bredemeyer Architecture site so those who want to read the narrative can do that. There are always so many things to do, and doing the things people want makes a certain amount of sense! Still, if that was the only consideration, much of our intellectual tradition would never have been built! Some of the progress we make because people build stuff. But, it is also true that we make progress because some people stand aside from the rushing hurly-burly of getting today's urgencies dealt with and make sense of things and distill the principles to guide the flow.
Anyway, I suppose that the selection of stories and the choices of art could be taken superficially as "pretty fluff" or as holding profound teachings for software design. I want the response to be "it is lovely" but more importantly, I want the response to be "it leads me from satisfying simple truths that help me make sense of our software world through deeper explorations that drop me into a rich thought journey that's taken me all kinds of interesting places. It informs how I think about and will influence how I design software-intensive systems."
I'll give you an example. We use the Taoist story of the master butcher (I've mentioned it before in this journal; I've also used it in part two of the Cutter Report). This is a wonderful story that illuminates the difference between the master and the hacker, and the distinction of mastery.
When we create powerful abstractions, there is some element of mastery and it is not purely technical but also something akin to the mastery of a poet who uses compression, allusion, metaphor and synecdoche; the visual artist who uses symbol and imagery, composition, abstract representation, etc.; and the engineer who uses analogy, sketches and schematics and more. These abstractions work if they are simple and yet hold meaning -- meaning that grows as the abstraction is elaborated and reified; meaning that is adapted as the abstraction is realized and shaped in encounters and interactions with its world.
One of the key points of the presentation is that how we use models and analogies and metaphors, and the representational language that we construct, has a shaping effect on what happens in the system.
I didn't use one of my favorite ee cummings poems in the presentation, but I find myself returning to it for it is such a great expression of how a simple "box" (or stone) takes on meaning we see into it:
may came home with a smooth round stone
For whatever we lose(like a you or a me)
I went to the sea in 2008, and of the thousands of pebbles on the pebble-strewn beach, this stone found me:
I went to the sea in 2009, and of the thousands of pebbles on the pebble beach, this stone found me:
Ok, I have a fun visualization for you.
If that last link didn't make you laugh (at my self-defacing satire), I give up -- I can't do anything with you. Let me recommend something light.
Sorry, just surfacing from an intense week (compounded, among a myriad other things, by corporate tax filing). My playfulness is odd, I do acknowledge. As is my seriousness. But what's even more odd? You reading this. ;-) I have steam to vent. You're tying to find ... what? A good question?
We see meaning into boxes (in our software models), in part because of who we are, and in part because of the context, the external world, and the world created by the boxes, the abstractions of our system. And we iterate, and develop and shift and enrich the meaning as we experiment, first in our mind's eye and sketches, then in code. That sounds complicated, but it is a realization that is developed over 100 very simple slides. Smile.
(If anyone says they understand that, I will think they are either really brilliant or have some screws loose, but I won't be able to tell so I'll have to assume the latter. Just as you do, with regards to me. ;-)
Curiosity is such an amazing quality, and it is astonishing that even among those who see themselves as avid seekers there is such a tendency to be dismissive! Arrogance is self-limiting!
Of course, anyone who reads here demonstrates exemplary curiosity, unquenchable optimism, and ... a superb sense of humor that copes as well with the tragicomedy of the human predicament as it does with base physical comedy and farce. E.T.C.
Alternatively put -- I'm a clueless idiot but if you are open to, like, the mysterious forces in the universe you will learn something by reading here. (not likely). Ok, let me return you to this and this and this.
Think I need a weekend off??? Tell Cindy!
Uh... it runs in the family... tonight, the kids took this portrait of our pet alien:
Well, it's neat having a 12 year old boy in the family -- he explained this xkcd to me. Somehow my education had managed not to hit Schrödinger's cat...
Aside: If you didn't click on the links, you only have yourself to blame for missing the farcical comedy of the below-the-stones section of this post. It is, you might say, an ironic mash-up with (your image of) me as the subject of play.
9/18/10 Building with Boxes and Things
Among all the word pebbles (and link Easter eggs) of the post above, hopefully you found this key insight:
how we use models and analogies and metaphors, and the representational language that we construct, has a shaping effect on what happens in the system.
We model named "things" (or abstractions -- of abstract things) and the names and the way we draw and talk about them starts to shape and inform what is built. That is the intent. But the point is that it is deeper and richer than putting a box on a diagram and giving it a label. If it fits, we choose a name that has metaphorical weight, that brings into our box a meaning and set of ideas from another domain. As we consider the abstraction through the lens of various views, perform thought experiments, start to build it out, the abstraction starts to take shape, to stand for, to mean a whole lot more than crude lines with a label. We add more names -- lists of responsibilities -- to the name. We give it roles, and cluster responsibilities and associate them with these roles. We consider ways this abstraction serves the system (behavior/dynamic interactions), we consider the ways in which it must excel (qualities/cross cutting concerns). All this adds to the expressiveness of the named thing that appears in our models and perhaps directly, perhaps in translation, in our code.
It would be so much fun to work on a software visualization toolset that understood that visualizing software needs to leverage design intent to be fully expressive. The code may be the fact, but the meaning (of abstractions, mechanisms, interactions, ..., the system) is created, ultimately, as an interaction between intent, expression and observation -- it is created by the architect designer, by developers, and by those who would grok the meaning.
9/20/10 More Making It Visual
More points about the Making It Visual presentation will out. It is all very well for you, for you can jump ahead. But I have thoughts I still want to catch by the tail and pin down, so I'm not quite ready to move on. :-)
I used a black background for the stories from history, images from art, etc. And gold for all that is directly software related. I considered using white, but I wanted software to be golden. :-) At any rate, that gives you an impression of how the presentation was designed to work -- to draw into and enlighten our thinking about software, and to allow our insights in the software realm to inform and enrich the way we see and search other fields, so we draw more again into ours. So, to provide a direct example, we used the story of fortress design of old to draw out principles that inform building robust systems today. You can simply state the principle, but it is so much more memorable and lively when told through the medium of a story. Etc.
Anyway, here is a slide from towards the end:
Iteration was a key message of the talk. The VAP take -- which encourages the cheapest medium for learning and making the decisions most important to the point we're at. Which typically means that early on, we're setting direction and making system shaping decisions by building paper models and drawing sketches. And keeping track of our reasoning, the rationale, assumptions, alternatives and so forth (or they'll be lost). The requirements line is drawn with an arrow pointing downstream, to signify that we draw more of the requirements activity downstream, instead of doing it all upfront. Architecture, development and testing all have arrows pointing left/upstream, signifying that we start these earlier -- so that from the beginning, architecture is concurrent with requirements and "testing" begins earlier. Of course, early requirements and early design are focused on the system vision and strategy (product/competitive/business strategy and architecture/technical strategy), then system concept (use concept and structural concepts). And "testing" early on is really improvement and then validation-focused activity aimed at the system direction/concept/high-level requirements and the architectural design.
It was an hour long keynote address, and there was much more to it than that. There was, I suspect, a lot more to it than any person got out of it. One tweet said something to the effect that the Tweeter's main takeaway was "make models and accept imperfection." That is important! One of the burdens of our zeal about models in the 90's is that we burned a lot of people with analysis-paralysis perfection-seeking and that branded visual modeling negatively in the minds of too many people. We truly, as a field, need to accept that our systems evolve, which means our designs evolve. But our systems evolve both because the context and need evolves and because we don't have perfect, full knowledge at any point, and certainly not a priori! This only means that sketches, paper prototypes and experimental designs, etc., are more important, not less, for they allow us to adopt a fail fast and cheap mindset to flush out good bets in terms of system use models and user experience design and design of the structures and mechanisms that deliver those value propositions. And then we need to keep working on design! Not just catching our models and documentation up to what happened to happen in the code, but being intentional about design. Intentional about making things more the way we want them to be! Again, models matter. Models are critical thinking tools for designers! All the more so, the larger and more intractable the code base becomes, with regards to thinking systemically about cross-cutting design issues.
When we interpret, what we see depends a lot on where we see from -- our own state, our own predilections and thinking patterns, our context, etc., has a bearing on what we see, and what meaning we make. So, if we want to see a dark, irrational, pointless cycling we can find it. But we can also resist that voice and tell ourselves "but of course that is a choice!" We can choose to see a playful cycling where the "reptiles" are different every time. Perhaps next time we'll explore the white space, and see what creature emerges. We can choose to excitedly, joyously see agile design captured in a vivid visual, with the sketchy models, the patterns, the emergence, the reification and realization, the experiment, the blowing smoke (are you just being teased, is it a point of failure, or an inventive new feature?), the bucket (recycling bin, or bucket of parts and ideas?) the reworking, and iteration.
That may seem like a pointless point. But it's not. We have to recognize that our models are in part what we make them, and in part what is made of them. Using a standard notation gets us some important distance along the interpretation path, but there is still active engagement that is needed to understand and align with the aesthetic and structural intent and architectural decision set.
As for analysis paralysis, that is where Escher's Eye comes in. So, ideas on points I think Escher's Eye invites us to make?
9/22/10 Making It Visual Continued
I've thought about putting the presentation on Slideshare, and probably will when I finish entering the narrative that goes with each slide. I know Slideshare doesn't care about the narrative -- garr! :-) But the narrative is needed to get more of my intent, so I want to simultaneously make that available on the Bredemeyer site when I put the slides on Slideshare. In the meantime, though, this side-by-side view is neat and not something you get from the Slideshare click-through!
These are the slides from the opening section, and each couplet has a story that is told:
Image sources: Feynman: Gleick's Genius; Feynman at 10: No Ordinary Genius: The Illustrated Richard Feynman; Louis Agassiz: wikipedia, fish: Hæmulon elegans drawing by H. L. Todd; Chuang Tzu: not ascribed when used here, so I need to find the source to ascribe it properly.
As you can see, the presenter -- or narrative if you weren't so fortunate as to see Dana in action -- is crucial, since the slides are there to illuminate and enrich through suggestion, not to tell the story. If you haven't read Surely You're Joking Mr. Feynman, I recommend it highly! The "fixing radios by thinking" story is told in that book. I mentioned Agassiz* in a journal post several months ago, and there is a set of delightful stories told by Agassiz's students of their first weeks and months studying under Agassiz, for the most part following the same pattern -- close, attentive observation of a preserved fish to "discover the relation between form or structure and function or essential effect." The last pair of story slides in that sequence focuses on the Taoist story of the master butcher. These all build a picture of the development path of a master -- for example, a master software developer.
I thought it was important to acknowledge and thrill to what we do when we write code! It is marvelous! Truly incredible, and I (and I'm sure you) so delight in what we achieve with software and how we do that!
And yet our systems grow and grow, until a car takes an estimated 100 million LOC! It is all very well if these are small, self-contained systems but more and more they interact, and need to be designed as systems, and systems-of-systems. Each one of which is becoming more complex. If we'd had two hours I'd have wanted to bring more about requirements and architecture drivers into the presentation, but one hour is both a lot (compared to a 20 minute timeslot) and a little (compared to a seminar). So, I kept trimming the material back to just one primary story-line and we focused on the design of architectural elements and mechanisms. But with the clear VAP spin on iteration and concurrent design of what the system will do and how it does it.
Architectural design has a quite different nature than writing code. It is true that we have to be sensitive to, have our sensibilities fully tuned up around, what it takes to implement the structural elements, the composites and mechanisms (elements flying in close formation, interacting to achieve some goal, some purpose or system quality) that make the system not only more than the sum of its parts, but more than a flat sea of classes. But the thinking, the considerations, are different, and we need to ask ourselves if 100 kLOC or 1 million LOC are a tractable medium for doing that thinking in... Well, you know my orientation to that, but I was surprised to find that not everyone is persuaded by the visual solution to the monk on the mountain problem (below). I used a "thought experiment" to solve that problem when I first encountered it, but as soon as I saw the visualization I thought that was much better. You can solve the problem as stated with a visual (as shown below), or you can restate the problem to convince yourself that the problem as stated is true -- in particular, you can have two people walk the path on the same day, both starting at the same time at opposite ends. Dana did this in the presentation, with someone from the audience walking from the opposite end of a line (the path), and still people weren't persuaded. Either way, you're creating a model to think through and/or demonstrate its solution. I suppose that this is somewhat like Necker's Cube (though that is perceptual and this is conceptual) -- once you see it, it is so obvious it is hard to understand how anyone could have trouble seeing it. Yet this is also a crucial lesson for architects, because we have to understand that the meaning of the architecture (and all the models, descriptions, ... specifications) is only seeded by our intent, but it is realized through the meaning that is made by those who implement and evolve the system (and those who use it, for that matter). And the meaning they make may be quite different than what we expect or think is "obvious"! Which doesn't obviate the need for models! We need tools to help us solve much more complex problems than this one, and to help others see the problem and the solution we propose. Some may need other expressions of the solution to grok it. We may need other tools to think our way to a viable solution. But we have to expand our toolkit for thinking and communicating, because the system complexity dragon is not going to put its tail between its legs and slink away!
Problem statement and Image Source: Rudolf Arnheim, Visual Thinking, University of California Press, 1969.
We really do need to get visual thinking into the problem solving toolkit early in education. Richard Feynman's father was phenomenal in the way he made things very, very tangible and visual to his son (the boy Richard Feynman), and look where that got him! But isn't it illuminating that we so sequential, algorithmic thinkers have a hard time thinking about concurrency and relationships and interactions even in so small a problem with a clear framing? Still, here we are, adults. The good news is, we can get better at this! Our brain, after all, is very adept at processing visual information -- in a flash, and even before heavy conceptual processing is applied, distinguishing relationships, patterns, differences. Many people in the visual thinking space go on about the amount of the brain that is devoted to visual processing, and it is true that of all the sensory input mechanisms visual gets the lion's share. When it comes to conceptual processing, words and images are both important, and it may well be that words then dominate. So what? Models, in words and pictures, help us think, help us frame and pose problems, and help us solve them. The more visual we can make something, the more we have brought to bear on the problem defining-problem solving process. AND we have brought it into a medium that allows others to interact with our thinking. Visual models and words cannot, should not, be thought of as competing tools but rather as complementary and both essential to architecting because architecting is so much about designing not just things (abstractions or conceptual architectural elements that we reify and transform) but relationships among those things -- relationships that make the system and give rise to emergent properties of the system.
Now, I acknowledge this was a challenging presentation to give in Germany--by which I mean, to give in English, in Germany. It is a presentation that can seem on the surface to be quite simple. A detractor might even say simplistic. But it is not in the least. At least, not as I see it. As I see it, it goes after what bedevils us in software, and that is audacious and challenging too, to boil down to a simple message. Or a seeming simple message, for the simplicity is rich with layered insight. I don't mean that egotistically at all, for the layers are drawn in, in a rich tapestry of reference and allusion. And I am not even responsible for all that reference and allusion. Many people, foremost among them Dana Bredemeyer and Grady Booch, have contributed to what is drawn in sometimes explicitly and sometimes implicitly in this presentation. But the point is, some of that reference is visual, and language independent. Some, though, was via stories and so forth, and relies then on quick internal translation when heard in English and the internal cognitive sense-making is (or would more comfortably be) going on in German.
* A note on Agassiz: Louis Agassiz has had a profound influence on how we study -- in various fields, from his own (paleontology, geology, natural history) to literature and systems. He is also infamous for his theories that became known as scientific racism, and his views and teaching in this area justifiably tarnished his legacy. This serves to highlight the fallibility of man's reasoning, not to undermine the importance of close observation and comparison! This human fallibility could undermine lessons we derive from others who made historic contributions too -- for example, James Madison, in the years after the Constitution, became a fellow we would not want to look to and emulate. But it would be a human shortfall of a different sort, to discount lessons we could learn from people who, despite their limited humanity, advanced some important dimension of the state of mankind.
Empathy and compassion are virtues that are much overlooked. It is too easy to see other's fallibilities, and perhaps doing so serves to distract us from our own. Can you imagine, there was critical backlash when Steinbeck was awarded the Nobel Prize? And that man made that speech! We humans are fragile, fickle creatures, but oh are we capable of greatness, capable of creating the extraordinary, capable of being extraordinary in challenging moments!
That negative reaction veritably extinguished Steinbeck's creative spark. When you speak the truth you see, remember that you see through your eyes, from your vantage point, with context you only partially see.
9/22/10 Words -- Kind and Meaningful
When I gave Dana drafts of the presentation, he was excited and pleased and his enthusiasm meant so much to me! He is such an amazing thinker and brings so much to the creation process, and I value both what he brings in and what he inspires in me. And I value the creative freedom he gives me, even when he is the one who has to "stand and deliver." Still, his enthusiasm for what I do is untellably bolstering. I pour a lot into making sense of our software world, trying to distill what is important in all the detail and clamor and drawing out the essential, and it means a lot to me when someone recognizes and warms to that. So I was heartened too when Daniel remarked that he values that I am candid. Now, I'd always thought of candor as telling the truth in an open way, which could be a piece of negative feedback on this journal and especially my Impressions post of 9/17/10 which, to the person who reads with sensibility, candidly reveals my uncertainty (not about what I see, but how I am seen because of what I see and say). But Daniel's point was quite different, and I learned from him that candid is a lovely word:
Of course, there is a "ruth" in truth, and I try to live up to my name but it is more a vision that inspires and aligns work than a done deal! :-)
As meaningful names go, we discovered recently (via Sara who was researching names for her novel) that Dana means "arbiter," which means a person with power to decide a dispute or a person whose judgment or opinion is considered authoritative. :-)
Dana has recounted a story that goes like this:
On a dark night, a man is looking under a street light. Another comes by and asks if he can help. The first tells him he is looking for his keys, and the second remarks that it is a fortunate thing he dropped them so near the light. "Oh no," the first replies, "I dropped them over there, but this is where the light is."
Now, I will candidly say I realize full well there are people who think that is what I do. :-) While I will, with equal candor, say I strive to shine a light where I see others overlook something important (to architecture or architects). So when I draw attention, the reaction often is not "that's new" but rather "that makes sense." Here is a comment from a Bredemeyer mailing list sign-up last month (8/24):
"The white papers you have made available are extremely useful. While they're not amazingly new discoveries, they're a collection of invaluable experiences and practices organized in such a way that the experiences you have learned can benefit others. Thank you."
That feedback excited me because it caused something to fall into place: making what we know make sense, and organizing it so that it is accessible, are important. So, for example, in the slideset for Dana's Making It Visual keynote, when I framed what Grady Booch and UML did for our field, and where that fits what we are trying to do today in system design, I was making pieces of our experience of history fit together in a new way. Well, it came together in a new way for me. So even if it is not new new, it is at least worth shining a light on because it is generally overlooked. :-)
What exactly do I mean? I'll get to that.
9/22/10 What We Ask For
It occurred to me that we so often ask too specifically for something. I said I'd put the slideset on Slideshare if someone asked nicely. Well, of course, I really mean any showing of interest would be impetus enough for me to summon the energy to put finishing touches (complete a careful attribution of all images, and add the remaining narrative) to it so I can put it on Slideshare and the Bredemeyer site. Ok, so I got an indication of interest without the specific request, and I'm working on it. But that's not the point I wanted to make. Let's take another example: Authors ask people in their network to put reviews on Amazon, when what they want is exposure for their book. Blog it up, review it on Amazon, put a link on your site; any visibility would be good enough, but the request is very specific. We should get better at crediting our colleagues with being able to come up with their own creative ways of meeting the goal we have, without being directive about how to fulfill the goal. Wouldn't it be better to say: "this is my goal, and here are some ways you could help me reach it"? That way we remain open to creative contributions, while being specific for those who prefer not to deal with ambiguity. More importantly, it gets us to think more explicitly about our goals!
9/22/10 Monday's XKCD!
Oh wow, did you catch Monday's xkcd? Dana says I'm not allowed to use it -- you can see where he stands on lightning! ;-)
9/23/10 Workshop Schedule
The Embedded Systems Institute has 6 or 8 people waitlisted for our Software Architecture Workshop that Dana Bredemeyer will be teaching in Eindhoven in early October, so they are floating a second workshop October 11-14. If you or a colleague are interested in taking the workshop in Europe in that timeframe, please let me know  so we can help ESI reach critical mass asap. We've also set the dates for the next EA workshop at last -- client dependencies always make scheduling tricky; don't get me wrong, we love client dependencies! :-)
So the open enrollment schedule is as follows:
9/23/10 Alright, Alright, I'm Getting To That
Here's the next set of slides in the series. I'll explain in a bit. One thing to bear in mind is that most of these slides only take a blip in time, but what this set is intended to do is to set context, indicating the shape and scale of the problem and illuminating a critical piece of history and where it positions us today. Remember the slide just before this is "we don't just fix software by thinking, we build software by thinking."
The word box is a snip from a Tivoli Audio warranty which says "Please resist the temptation to take apart your clock radio. There are no user serviceable parts and any attempt at modifying or repairing your radio will void the warranty"
Image sources: 3 amigos, don’t know who to credit as these are used variously on the internet and I haven't located the original source. UML collage: wikipedia; UML trademark logo, OMG; OOAD convergence map: wikipedia; Vermeer’s Woman Holding a Balance, in National Art Gallery in Washington DC; http://commons.wikimedia.org/wiki/File:Woman_Holding_a_Balance_(Vermeer).jpg; "UML took it literally" image: Michele Lanza, presentation titled “Of Code and Change” on SlideShare; fellow reading and towers of books: Arnold Lobel [1933-1987]; Facade image source: Failblog http://failblog.org/2009/10/07/house-fail/; Fox in the Hen House by Adolf Mackeprang (Danish, 1833 -1911) image at http://www.designsourcect.com/productsandvendors/fineartandmirrors.html; Boston Symphony Orchestra, http://www.bu.edu/today/files/images/articles/BSO%20(Michael%20Lutch).jpg; snip from Eric Whitacre’s Virtual Choir video on YouTube http://www.youtube.com/watch?v=D7o7BrlbaDs; hand and puzzle source: http://www.pureplaytech.com/
"If you can't draw a picture of it, it isn't a pattern." -- Christopher Alexander, The Timeless Way of Building, 1979, p. 267
UML wasn't essential for patterns -- indeed, the GoF Design Patterns book predated the UML. But it did use precursors to the UML, and visual representations of software abstractions were and are important in describing the mechanisms documented in patterns. And yes, (if memory serves correctly; it's been that long) we had watchdog mechanisms before the patterns concept was borrowed from Christopher Alexander's work in building architecture and city planning. Etc. One can devil's advocate anything (even that devil's advocate statement itself)! :-)
Nonetheless, I think a reasonable case can be made that the design method work of the likes of Grady Booch, Jim Rumbaugh, Derek Coleman and others, and then the UML, ushered in two important features of our design landscape -- a broad acknowledgment that software abstractions can be modeled visually, and the use of visual modeling in describing mechanisms structurally and dynamically (supplemented, of course, by words/textual descriptions). These descriptions were usefully further supplemented with when and how to apply proven mechanism designs, and we have patterns.
Yes, yes, what Booch and Rumbaugh did was not without any precedent. For example, Booch's infamous clouds (I've come to respect the notion of clouds or at least imperfect hand-drawn boxes in early sketchy models or diagrams) have heritage in Entity-Relationship Model work by Peter Chen dating back to 1976. Booch was writing seminal papers on Object Oriented Design in the 80's but his book came out in the same year as Rumbaugh's, followed by more methodologies like Fusion, and a battle for mindshare was fracturing the space, making it hard for development teams and tool vendors to pick which methodology/methodologies to use/support. All of which only underscores the point! Convergence to one notation (at least within each generation or revision of the UML -- don't get me going!) was important to the maturing and consolidations of knowledge in our field. So while a good many people were making very important contributions to software design, and especially making visual design a practice within software, Grady Booch was, at every turn, playing a leading and shaping role in terms of the direction and practice of visual design. Grady gets a lot of well deserved credit for the UML -- not that he did it by himself, but for the role he played both in initiating the UML standardization effort in the first place, as well as in the content and expression of the first iterations of the notation standard. But he has played a more fundamental role as the prominent visionary leader in the art and practice of visual design of software. Do I sound like a cheerleader? Well, I've said before, I'm the self-appointed chief cheerleader in Grady's fan club. Jokes aside, I think I'm making an important point. The UML is a modeling language, and it primarily focuses on and enables visual design, or the visualization of software designs. And Grady deserves a large share of the credit for that bigger contribution to our field, for he has been a shaping force at every turn, in the founding and establishment of design, and visual design, as a practice in our field. Visual design, that is, that relies on the notion that software abstractions can and should be modeled visually to aid us in reasoning about and designing more complex software systems.
Now, we might have committed crimes of over specifying and becoming overly pedantic and precise especially prematurely in the design process. But just as we don't credit (or blame) English for Shakespeare or Hugh MacLeod (both masters in expressing the tragicomic human predicament, though Shakespeare did so rather less personally; who I am to mention that, though), we should not blame the UML for over-zealous, if perhaps naive, application thereof.
I could explain more. For example, I could tell you more about what I meant by "perhaps we were too literal" on the slide where I use the "UML took it literally" slide from Michele Lanza's presentations on software visualization. Eh. But, don't you like my use of Vermeer's Woman Holding a Balance? (I love that painting! Aside from how I was using it, architecture is so much about weighing and finding a balance between the more immediately material and the harder path of integrity.)
Well, that gets us half way through the slides but these were quick flips to build the context. The slides from the remainder of the deck are more dense. (As if all that wasn't!)
Ok, so now you want more, but not in this format? ;-)
Sorry! I'm working my way there. In the meantime, I like this layout. Think the good folk at Slideshare are listening? It makes a point about visual models too, in that it is a quite different experience to look at 4 slides at a time than 1 at a time. We see the relationships.
9/23/10 Escher's Eye
I work really well to deadlines. Whenever they are past, I pull myself together and in a (relative) flash produce what I was stalling on. Other people are better at having the deadline produce the same effect in advance of the deadline. ;-)
So, I stalled and stalled on the Making It Visual presentation while ideas swirled, but actually created the stupid thing in the few days before Dana had to go live with it. The deadline ostensibly was before Dana left for Germany, but hey, there are deadlines, and there's a hard wall.
The neat thing about all the work that occurs during the "incubation" or "stall" phase, though, is that it prompts a ranging, joyful exploration, so the crunch-time synthesis and iterate phase has plenty of grist.
How does that relate to Escher's Eye? Is it too much of a stretch to go from realizing that mortality factors into and shapes our (sense of urgency around our) aspirations and views, to the role that deadlines play in creative, formative endeavor?
Yes, that gets you most of the way to the answer to the question I posed days ago. ;-)
It just occurred to me that I could make a rather "lovely" presentation based on the Art of Change paper (which Ryan quite properly calls the (for the delicate, 12-year old boy language follows) "fart of change." I won't tell you what he calls his parents. ;-) But, 12-year old ribbing aside, I think it'd be a neat topic for Dana to present at an EA conference. Sigh. I'm never invited to present. I wonder why? Oh right, when there's something mean to say, all of a sudden the question is not rhetorical. ;-)
Oh, yes.... Up after the Leading Change paper, is hurling the long, long overdue VAP book through to print.
Hugh MacLeod says "Remember who you are." I saw a bumper sticker that said "Remember who you wanted to be." I think the latter is an important reminder. I saw another bumper sticker that said "Live the life you love." I guess "Follow your bliss" (Joseph Campbell) would make another great one. They are all informed by Escher's Eye. But, be warned, that skull gets larger the further you get from 40. :-)
9/24/10 Visual Design and the Visualization of Design
One of the places I land, when I think about software visualization, is visualization of the code structure is important and illuminating. But our conceptual design elements are more rich than classes and packages. And relationships are more rich than static dependencies. So we need our visual designs (expressing our design intent) to inform our visualizations of the design embedded in the code (the design as realized in the code and reflected back to us through the design visualization), and for our visualizations to inform our thinking about the design. Lattix, and tools like that, do this at the structural element and static dependency level, and I love the simplicity of the dependency structure matrix (DSM). Of course, a DSM is a matrix, and design intent is specified through design rules, so the visual aspect is fairly rudimentary and yet very powerful! With just a bit of introductory explanation, it is quite easy to grok, a good part of the power of the DSM comes with knowledge of design intent. So we're back to the importance of expressing the design intent!
And yes, as we point out time and again, words matter! Keeping track of the reasoning and rationale, the assumptions, the alternatives weighed but decided against, etc., is vital! The computer doesn't ask why before executing an instruction, but the computer isn't expected to change the code on its own initiative! The designers and developers now and in the future need to know why, and under what conditions, etc., because they will have to evolve the code! So they need to know what the design is, and why it is the way it is, so they know what changes are reasonable and which are not, given assumptions, context, and reasoning that the processor didn't need in the code. Architecture documentation is important because many minds will engage in building and evolving the system. Visual models, even if we were to think it reasonable to take them down to explicit detailed designs, also (like the code) simply do not contain the thinking that makes the judgments make sense only the results of the judgments, nor the context, only decisions made hopefully with insight into the context, etc.
Yes, I'm still covering the substance of the Making It Visual presentation. :-) It is hard for me to "move on" from it, without debriefing myself on what swirling concepts and insights moved into a new formation for me in the process of drawing that presentation out.
Then again, I could write an illustrated essay about visualization using the images in Brian Zimmer's "Oh look a Marmot" post and it would be visually splendid and I'd learn (that I know) a lot about visualization in the process. There is always such a tension between doing something new, and reaping what we learned from what we just did. I wish Brian would pause from the doing to reap another photo blog post! I haven't been able to get to any mountains or beaches lately, and I know I could look more closely at our local fungi but Brain helps us see even in the most dowdy (to our glancing eye) mushroom a delicate belle of the forest!
Oh, speaking of not looking closely at mushrooms... It occurred to me running in the woods that that metaphor might work nicely for the cross-country runners in the software world. The first section of our routine run is uphill and a good warm-up. Then the route goes along the crest of a set of ridges, with lots of twists and turns and some mild slope texture, before going downhill back to the car park. Along the ridge it is so wonderful to open up the stride and pick up the pace. But it is full of those twists so not much of the path is ever in view ahead. And it is forested. So lots of roots, though there are clear stretches. Why do you have to know this? Well, as soon as one picks up the pace, especially in the rooty places, one can scan a bit ahead every now and then, but really one has to focus a meter or two out, or it will be a mouth-full of dirt or a twisted ankle! At a jog, one can look around at the forest, but at a run, one has to be much more focused on the path just ahead. Ok, maybe that doesn't mean anything to you, but it made me think of the importance of the architect paying attention to the path ahead when the team is heads-down focused on agile sprints. Especially in the gnarly, rooty spots. Sprints and kanban create commitment to peers to deliver near-focused chunks of functionality, making it important that someone has and is doing a broad scan, thinking systemically, thinking about where the system is headed, and setting architectural context.
An architecture program manager told me he is criticized for drawing parallels and using metaphors so much... and I do that too. But here's a thought: People who are that easily miffed have themselves to live with, so let's not let them live too much in us too! In my journal, I'll learn from whatever serves me. If you don't learn along with me, hey, you just saved yourself a whole lot of reading by deciding I'm worth ignoring!
Now you see why I call this a journal NOT a blog. It's not just the lack of blog accoutrements like comments, permalinks and LIFO structure, but also the style, the personal thought processing, the not altogether tidy organization given the stream of consciousness thought tracing. How did I get from visual design to dodging roots anyway?
I have had people tell me they can't even draw a mindmap; they're just not visual thinkers. Well, I've always been an active outdoors type, but for most of my adult life I'd never have, not even for a moment, contemplated running... hiking, cycling, kayaking, cross-country skiing, YES! Running? You kidding?! But I love it. So, we can do things we don't see ourselves being physiologically set up to do. Escher's Eye helps. Wink. But in every arena, from math and the great work Paul Zeitz is doing along with work on diagrams in math and logic surveyed in this article on the Stanford Plato site (pointer from Grady Booch), to business and the great work Dan Roam, David Sibbet, Nancy Duarte and others are doing, there is a renaissance in visual thinking. (That's a spectrum, not a definitive list!) At the same time, the likes of Utterback at MIT and Tim Brown at IDEO are emphasizing a design renaissance, and these two (visual thinking and design) have a confluence in visual design. Colin Ware (Visual Thinking for Design) has done thought leading work in this area, and I'm happy that we were doing pioneering work (leveraging what was being done in object-oriented design and then UML, but focused on architectural design) in the mid-90's with what, in the later 90's, became the Visual Architecting Process.
Visual design, to dodging roots, to visual design. Ah, the playful mind can tie the most unlikely threads together. ;-)
When Invictus was showing on the circuits, I was swamped and before I knew it, it was off. So I'm afraid I only got see to it tonight, and wow, if you haven't seen it, or didn't relate it to leadership, system thinking and architecting across divisions, I sure do recommend seeing it (again)! Ah, the power of words to inspire! Of course it is a fictional account based on real people and events, and I gather quite some poetic license was taken. Still, in the large it conveys accurately the context, attitudes and changes. Nelson Mandela is beloved by the South African nation, including the whites who were very fearful at the transition in power. The movie lines, some quite funny, lend themselves to drawing leadership lessons, and while that could be seen as a fault, I think it works really well. As a movie about history, I'd have wanted more accuracy, but as a movie about leadership and reconciliation I think it is superb. Even as a movie about history, I think it did a good job of conveying the spirit of Mandela's leadership and role, despite being reportedly inaccurate/misleading about the specifics of his role and actions leading up to the world cup win. It is hard to not feel a little cheated/lied to by the inaccuracies, but the bigger message about the changes that Mandela did indeed lead, his personal integrity and powerful charisma, his reading of people, his humanity and goodness, is important and did come through well. Ultimately those are the big things that we need to remember, and feel. Besides, even our own memories of our own lives are rather fictionalized because we don't have perfect memories, don't perceive perfectly, and tend to romanticize (or see kindly) our own actions and rationalizations of them.
9/26/10 Tick Tick
Not much left of September! So much to do!
9/27/10 Tick Tick -- Tick!
This morning I awoke from an unusual (for me) dream. Ryan came to join us while we had morning coffee and while I don't usually describe my dreams, this one was, like I said, unusual. There were three scenes, the first two brief, the third more involved. I said, "I don't have dreams like that" and Ryan said "Not until you were [age reference deleted; hey, I'm a Q<=]." And suddenly the dream was transparent -- deep water; on a ledge; the parents are about to be executed and someone has to save the kids. Oh dear. Still, it reminds me what visual-verbal creatures we are! The highly visual processing of a dream unlocked by a translation not of the action of the dream but the idiomatic and metaphorical content of what is rendered into the highly visual world we encounter awake and asleep. So we say "visual thinking" to emphasize bringing the visual back into our (individual and collaborative) thinking and communicating toolbox, but it is worth bearing in mind that verbal and symbolic thinking tools are not turfed out but complemented thereby.
Oh yeah. I do like Vermeer's Woman with a Balance. :-) I don't pay any attention to birth signs (to make that clear, it was Sara, looking at a joke horoscope, who discovered and brought to our attention this year that our fishhead is a Pisces; we laughed and laughed at that, because it took us 12 years to find out, and it is so right!), but yes, I'm one of those "women with a balance." Serendipity has a sense of humor. ;-) [Right, and in that horoscope, it said that Pisces have real trouble with Librans! As I said, it was a joke horoscope. But our Pisces' sibling is a Libran. ;-)] So, Google is a Libran too. 12 today! My, what a big shadow Google's cake casts. :-) Visual creatures. Persistently always-on sense-making creatures. And... Fallible creatures. Oh yes, I'm still dealing with the content of the presentation. But very obliquely. [No, I did not mention, nor even allude to, the signs of the zodiac, nor Google's birthday. The slides did mention fallibility and our human drive to make sense, even when the sense we make is pretty nonsensical.]
9/27/10 The Value and the Price of Criticism
I think the Dreckstool site (thanks to Stephan for the pointer, via Dana) is a good idea, so long as people keep things in perspective. Negative feedback can be hard for some people to give -- and too easy for others. I was just reading some reviews of the Eragon books by Paolini, and it is shocking how the critical reviewers completely miss the point! So what if it is derivative! Goodness, anything completely unprecedented in this day and age is highly unlikely, given the mass of works that have gone before. So that cannot be a point of useful disparagement -- especially not in a book for children. I haven't read the books, but I've read and listened to several chapters, heard Dana and the kids' discussions and hypothesizing about what comes next, and seen the kids immersion in the characters and so forth. Sara is racing Paolini to write book VI. And I'm sure she is not the only 10 year old to be so inspired. The scale with which Paolini has captured an audience is an important factor! Likewise with the tools some may love to hate. :-) Which is also important. I'm sure the "worst tool" list toppers are doing what they can to turn those impressions around. And I rather expect Paolini is having a harder time with book IV given the success and all those expectations, and the negative reviews and the motivational hit negativity carries. When I think that the small-minded stupidity of the critical response to Steinbeck's Nobel award so knocked Steinbeck off motivational equilibrium that for his last 6 years or so he didn't write, I'm frustrated by what that cost our world! Yeah, we don't want o-rings to fail for the lack of questioning assumptions. But small-minded negativity costs us too! I don't mean to defend HP Openview. I have no ties to it, and no reason to defend it. It only is reasonable to think, though, that the weight of the user base is pretty heavy at this point, making it very hard to make everyone happy. Success can become a millstone. Apple discovered that with AT&T's service level. So, we want to give a voice to discontent, to motivate addressing real issues.
Too much balance can be a pain too. I know. I have to live with me! Seeing alternative perspectives is a blessing and a curse.
(The thing is, excellence comes at the price of much self-criticism, and motivation comes from an overriding belief in the value despite the constant effort to improve where it matters and let go of what does not matter to the value one is striving to deliver. But external negativity serves to give weight to the internal critics, and can be the undoing of an effort that is ultimately valued and esteemed. This goes for individuals and for organizations.)
9/27/10 Dot Diva?
"The Dot Diva project was developed in late 2007 to address double-digit declines in enrollments for graduate degrees in computer science. Despite some improvement in these enrollments since then, the number of computer science majors is still not meeting projected workforce needs, and women are particularly underrepresented in this field. While many factors contribute to the low interest in computer science, misperceptions and negative images play a significant role. Project leaders determined that underlying image issues stem from deeply rooted beliefs among young people, including a feeling that science is too hard, and overexposure to media stereotypes of socially isolated programmers."
-- ACM news, 9/27/10 (full article)
I'm all for a re-imaging of computer science and software engineering, but "dot diva"? Why don't we target all races and genders by highlighting software as a partner technology in every field of endeavor, from life saving fields like medicine or crisis intervention services like the Red Cross to investigative sciences like chemistry and astronomy, to social services like the police or charity services? Just as plenty of boys are put off by the stereotype of nerd-machismo game programming, I can only imagine there will be girls who are put off by diva anything too! The people who write software can, but don't have to, be cool "divas" or uncool nerds. Like many fields, there are social aspects and think-alone aspects. It is a highly creative, highly cognitive field, and it is often very much a team endeavor with, in many cases, an important social agenda. We're so messed up, we think this is just about bringing Q<=s into CS/Sw Eng, but it is about bringing all kinds of people -- meaning a diversity of young people -- into a field that is only going to grow.
While we are at it, we need to stop sending out the message that girls don't want to do subjects or enter careers that are hard! That is the stupidest message I ever heard because it totally ignores the effects of stereotyping and self-fulfilling conclusions. We have to get better at saying in every field there are ways of encountering and thriving in the field that are as diverse as the people entering the field, and the more diverse the people that enter, the more the field itself thrives!
We need to ditch the stereotypes, not add new ones! We need to make it a more inclusive field, not a more exclusive one. We need to understand and value diversity of problem solving styles, so we don't foist our blinkered biases onto our children. Clearly there are differences in males and females -- across and within genders. And clearly men and women excel in a variety of fields despite stereotyped views of those fields -- not because we are all the same, but because we are different, and our differences enable us to make contributions that together add up to more!
Personally, I think getting press for the folk at Crisis Commons would go a long way to raising the image of geeks among girls and boys. And then we need to provide different entry points for kids to get introduced to software development. For some kids it will be modifying and then writing games. For others, it might be part of a community service project. A banner project might be something like "Create a localized posting service for missing pets and track found pets, and for getting foster homes for kittens while finding an adoptive family." Or we might catch today's "Grady Booch" wanting to do "discrete simulation of the collision of two particles." Whatever project a kid cares about, there is software to be written to help in some dimension of the endeavor. Let's show them that side of what we do! The bottom line is, if a kid hasn't had any exposure to coding by the time they hit college, they'll be at a disadvantage. We need to accommodate for that too, but we also need to get more kids excited earlier, and game programming is only one avenue -- a rather exclusive one at that.
Why do we think we need to make it fashionable to be in technology? Can't we just focus on what is enjoyable and enriching (materially for those who want that, but I mean personally and interpersonally) about a career in software? And then empower people with different cognitive styles and different interests so they enter CS and SW Eng with the kind of confidence that comes with practiced familiarity.
Aside: If you don't get Q<=s, you must have missed Rives on Mixed Emoticons.
'"Larger percentages of these professions are attracting women," says Betty Shanahan, executive director of the Society of Women Engineers. But, she says, disparities persist among strictly engineering majors, where more than four in five are men.
In the sciences, women account for a majority of graduates in psychology and the biological sciences, 2007 data from the National Science Foundation show, but trail in engineering and computer science, around 18% of both majors.'
-- Census: Women closing in on male-dominated fields, USA Today, 9/29/10
Charlene Begley is GE's first female senior VP. First! GE is a centenarian!
And good for NBC's Lauren Zalaznick -- not only has she succeeded despite any sexism hurdles she's faced, she's braving ageism too! She's the only woman in Fortune's 50 Most Powerful Women that clearly doesn't dye her hair. (Well, a few, like Google's Marissa Meyer, don't have to contend with that side of ageism yet.)
9/27/10 EA in 160 Characters
The challenge to describe EA in 160 characters has prompted 1,347 comments on the Enterprise Architecture Network LinkedIn group. Doesn't that tell us something? Yes, precisely -- rather than reading upwards of 20,000 words discussing and defining EA, it would be a whole lot more effective use of time to read our 17,400 word The Art of Change: Fractal and Emergent paper, which positions what EA is, and does a lot more besides. ;-) Oh, I'm kidding. I do value discussion. No, I have not read all the comments. I did pay attention when the discussion thread started up. If someone wrote something I ought to read, let me know, ok? If it can be done in 160 words, I'd like to see it! I punted on a software architecture definition and focused instead on the "central concerns, key decisions." It gave me the scope to use more words. ;-)
The next most discussed post (with 450 comments) asserts:
"EA is not the glue between IT and "The Business", EA is the glue between Strategy and Execution" -- Kevin Smith
One person already observed that glue is perhaps a sticky metaphor.
Dean Thompson said something like "Architecture is the translation of [business] strategy into technology." I'm going on memory -- Dana's memory. I learned a lot from Dean, but he said that to Dana. Dean was the architect of the first version, and subsequent generation or two of HP Openview. Now, HP Openview has become like the highway and major road system in Germany or the US in and around cities. The latter are critical to the functioning of the city and inter-cities, the system is massive and the dependencies are huge, making it neigh, if not actually, impossible to rebuild from scratch. So it should not be too surprising that Openview can be an unpopular tool in the IT operation center toolset. But before a tool can earn that degree of opprobrium, it has to be very successful! And Dean laid the foundation for that success, and is in no other way to blame for the current inertial weight and whatever else it might be faulted with. It has just been too long since he had any involvement with it. Dean moved to HP Labs around the timeframe I moved from HP Labs to the HP Software Initiative (independent events, I assure you), and in the HP-Agilent split, HP lost Dean to Agilent. And HP lost me to babies. That next generation thing!
I might tweak that to "Architecture is the translation of [business] strategy into terms that can be implemented." Whatever. I don't think that is a satisfying definition of architecture (software, system or enterprise), but any definition that ignores this aspect is also incomplete, or missing the point. ;-)
9/28/10 Um, Dismissed
Ok, I have to put a final surge of focus on the To Lead paper for Cutter, so I have to drop my debrief of the Making It Visual slideset at this point (half way through the slides). Apparently no-one wonders what comes next anyway. But it's good -- really. I know, I know, you'll take my word for it. ;-)
Before I go, just a word about my emphasis on visual in visual design. First, I think that design is of ultimate import. And we (in VAP) use lists (e.g., lists of responsibilities) as a design tool just as we use behavioral and structural models. And we document decisions with textual descriptions, rationale, etc. It isn't just good discipline to "document" the architecture; we learn a lot about it in the process of explaining it to ourselves and our peers through words, and words are as important to design thinking--the thinking process--as diagrams and more carefully define/specified models. So you could say "(visual) design," to give design the bigger play, but to bring visual into the picture. I'd rather just say that we are doing design (architectural design, that is) and we highlight visual because the visual models are crucial (just not the only) thinking, communicating, testing tools for software design (for systems of sufficient complexity to benefit from explicit architecting).
"In technology, the conceptual age is defined by cognitive or creative assets, including design, storytelling, artistry, empathy, play, and emotion. Good engineering or good computer science is no longer enough; design must be just as good."
-- Michael Zyda, Computer Science in the Conceptual Age, Communications of the ACM, Vol. 52 No. 12, Pages 66-72
'So, long live the phrase "design thinking." It will help in the transformation of design from the world of form and style to that of function and structure. It will help spread the word that designers can add value to almost any problem, from healthcare to pollution, business strategy and company organization. When this transformation takes place, the term can be put away to die a natural death. Meanwhile exploit the myth.'
-- Don Norman, Design Thinking: A Useful Myth, 6/25/10
Don Norman can be flamboyantly opinionated and contrarian. As much as he invites thought, he provokes thought. I don't think he'd take that as criticism. He wants people to think afresh about design.
The only reason I am comfortable being anywhere close to the visual and design bandwagon is that we were there long before it was a bandwagon!! And while I draw threads from many sources and lineages, I weave a distinctly individual course. You'll find clues everywhere. For instance, instead of having the traditional cover slide to Making It Visual, I had a cover slide to the cover slide. :-) No, it wasn't that I couldn't decide! The things you think! No, I wanted it to be clear that the talk was a conversation between interesting, thought-provoking, informing other fields, and ours. And I didn't want the talk to be in black and white, the way so much of our yin and yang world is. No, black and gold! Still binary, but not stereotypically so. ;-) As for the rest of the talk, well, maybe I'll get around to sharing it. After I'm done with To Lead! I by no means claim it is a great set of slides, nor even worth your time necessarily. But if no-one wants to draw that conclusion for his or herself, then it says everyone came to a foregone conclusion that it is not worthwhile, and that is not healthy. Certainly not healthy for me! :-)
It... might hold some interest... For example, in this age of the Stuxnet Worm and forces giving rise to the Rugged Software Manifesto, fortress design presents clear principles and makes for a compelling story to weave into your design narrative. Did you know that Leonardo da Vinci was one of the artist/engineers who worked on fort design? Security in those days, and today, warranted great minds working on the problems! Great minds, and making new connections, to bring about innovative, creative solutions.
9/29/10 Flushing the Cache
Yes, I know. I have slacked off on trimming back entries in September. Partly it is just that there is work involved in trimming, and the overhead to value ratio isn't there, given that this is a "quiet backwaters place" -- more quiet since I disconnected the archives, reducing the chance that this journal is found via a Google search (not my intent, though I don't mind that result). But, having disconnected the archives, I'm not as cautious about what I leave in the public view, because it is only accessible until the next month's tide washes it away.
I suppose that is not very kind to those of you who visit here with any regularity, for there can be just too many (too playful; too personally cast) words. But it's a journal! My journal. By which I mean, it has to serve me or it won't keep my attention. If it doesn't keep yours, I regret that. But it's not necessary in the way that keeping my attention is necessary! So, 4.5 years into journaling here, I know that this journal will be absolutely idiosyncratically me or it will not exist; I have never been a "popular" sort and have never sought to be. So, while I value the company I get here, I will not compromise the value I get from freedom of expression in order to appeal more to the "mainstream" pedestrian reader. There are other venues for that, and I keep intending to reap entries into my blog, etc. But in the time that I have to be a "cut-loose" exploratory "awe-struck seeker" following my curiosity and tracing some of the trail here, I don't want to be worrying about larger appeal and restraint on post length/frequency/style.
I have, in the playful style of this journal, been exploring the footnotes to the narrative for the Making It Visual slideset and elements of the "To Draw" section of the To Lead is to See, to Frame, to Draw paper for Cutter. This is where some of the thinking steeps, readying itself for more formal avenues of expression. So I value this journal, even when I know full well that it is highly dismissible to all but the most unusual reader. Unusual? You know, extremely smart, extraordinary sense of humor, and interested in everything from how we craft more resilient yet fluidly evolving abstractions to how we deal with the political shenanigans of some developers (who claim no particular political adeptness, yet successfully derail architectures and architects if they're getting in the way of what they want to do) and managers. And precisely because some have no compunction about undermining others, I am very happy that the veil of words has this real benefit of turning away folk who are unfriendly to this mode of expression -- critical, undermining voices would simply shut this public view down. I was not socialized to take cruel negativity "like a man." ;-) But I also don't seek it out.
So, the cache will generally be flushed at month's end. This month, what the heck -- I'll flush the cache early!
I may try to be more careful to trim back posts in October. But probably not. At least, not while the current experiment with respect to the archives is in play. (It has the disadvantage of not being able to link to past entries, and gradually Google's indexing of the past entries goes away. Google's indexing gets more and more useful, the longer I write here -- people remark on my memory of past posts, but getting at the detail, the specific set of the words, requires being able to access the post itself, and my memory doesn't extend to exactly which month the post in question was written. So, we'll see. Ultimately it is a balance between shielding and serving.)
I called this journal A Trace in the Sand, because nothing we do is likely to have any permanence. (If I wanted that, I would have made my life's focus writing poetry!) So, making this trace more evidently just that -- an impermanent trace in the sand (or silicon) -- appeals to my quirky ironically tuned sensibilities.
[The decision to disconnect the archives had to do with parental consistency, not this journal per se. Meaning if we restrict what our kids put online, it seems only reasonable and fair to limit what I leave on the public i-way. Since the monthly archives held no value except to me and it would be real work to extract the non-personal from the personal, I decided to remove links to the archive. It means that the few who want to check in on my current trace, can still do so. And I can write in a way that is natural for me given that this is my journal, not a formal forum for expression. Perhaps down the road I'll trim off the personal and map out archived posts, but not now, and not soon.]
[11/20/10: I have replaced the archives in their "old" spot (hence again connected to the Bredemeyer site, that being pretty much the only one that references specific journal posts). Partly, I want to create a topic map so that I can make my discourse on various topics available to those interested, and I want Google's indexing to help me in that labor of love or vanity, or both. ;-) A friend once said of this journal "there's some good stuff in there" and I rail at that "some"! I think there's a lot of good stuff here, and therein lies the problem. Too much good stuff limits its own value, for who has the time to grok so much good stuff! ;-) Oh yes, there's a lot that is personal, and to me that is a good part of the art of the thing. I think that we are at a point in history where it is not the proclivity of an exclusive few who get to wrestle in the hum-drum of the day-to-day with what it means to be fully human, to battle with what it means to lead a good life (outside the extremes of being a Mother Theresa).]
This pointer by way of Daniel Stroe: Software Architecture Anti-Patterns
9/30/10 Architecture Workshops
Our next Software Architecture Workshop in the US will be held in Boston, MA on November 8-11, 2010. The next Enterprise Architecture Workshop will be in Chicago, IL, on December 6-9, 2010 (the early enrollment discount deadline for the EA workshop is October 8).
The Software Architecture Workshop next week in The Netherlands was full and waitlisted, so the ESI has opened up a workshop the following week (October 11-14). There are a few places still open in that workshop, so if you want to take our workshop with Dana Bredemeyer in Europe in 2010, that is your opportunity to do so! If you want to enroll, please let me know () even though you will enroll through the Embedded Systems Institute.
Architecture (enterprise, systems and software) is a real focus of investment in The Netherlands, and they have a long history and critical mass of management support for architecture competency. You might say that this is a result of having to do more with less, because it is a small country that produces world-leading products. It certainly is a country that puts a lot of emphasis on engineering excellence.
We ran our first open enrollment workshop outside the US in Utrecht, and we did have a few folk from Germany and the UK at that workshop, but for the most part it was architects from The Netherlands. In some part, it was because I already knew architects there from Fusion user group meetings at ECOOP and OOPSLA. In addition, strong players in INCOSE and IEEE architecture working groups are from The Netherlands, and Gerrit Muller is one of the superb Dutch architects who have been a force in creating architect community in The Netherlands and globally.
Note on my "creating a visual narrative" sketch: you can see I drew the people afterward -- more "art of drawing people in." It is funny how mistakes often reveal something that works! Because, of course, the visual narrative does have this property of drawing people in, of getting people interested and engaged. Yes, you still need words. Yes, writing and conversations are still of huge importance. The visuals help clarify and energize and propel those conversations, and the words are the medium in which we also, creatively, critically and crucially, think and communicate.
Here's a tweet from the workshop in Germany earlier this month:
Aside: I just discovered I love Twitter. Here's why -- one person who follows my tweets also follows Bill Gates and Uncle Bob. That's a neat spectrum!
I also write at:
- Bredemeyer Resources for Architects
- A Shout
- In Kind
- Dot Diva
Architects and Architecture
- Todd Hoff (highly recommended)
- Anna Liu
- JD Meier
Architect Professional Organizations
Agile and Lean
Agile and Testing
Other Software Thought Leaders
- CapGeminini's CTOblog
CTOs and CIOs
CEOs (Web 2.0)
- Don MacAskill (SmugMug)
- Wired's monkey_bites
Social Networking/Web 2.0+ Watch
- Dan Roam
- David Sibbet (The Grove)
Strategy, BI and Competitive Intelligence
- Freakonomics blog
Um... and these
- CNN Money Business of Green videos
|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 firstname.lastname@example.org. 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! Bring value, and 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|