-- Kat Austen, Colour me beautiful: Wellcome Image Awards winners, NewScientist, February 2011
"It’s OK, he’s playing you as a kind of supergeek. That should be enough to put people off.”
A Trace in the Sand
by Ruth Malan
3/1/11 BearingsThis is a journal, a playful thoughtscape, where I trace of some of my exploring and thinking about topics I relate to architecting and architecture, and how to be a great architect. Well, it is a journal, and sometimes I succumb to a "personal moment" but I invite/allow even personal moments to teach me. So what is here is just a trace of some of my encounter as I romp and play in this wonderful land of software and its architecture, and all the territories beyond that I investigate to bring insight and (conceptual) tools to bear on creating great systems.
3/1/11 Call for Papers
VARSA 2011 : 1st International Workshop on Variability in Software Architecture @ WICSA2011
3/1/11 Chapter Outline
We were invited to submit a chapter outline for a book (in proposal stage) on enterprise and system architecture, and I suggested something along the lines of our Art of Change: Fractal and Emergent paper. The draft outline is as follows:
Choreographing agility: strategy and architecture in tandem, by Ruth Malan and Dana Bredemeyer
In this chapter, we
discuss the relationship between business strategy and architecture at
different levels of scope, giving some background into the key concerns
of both strategy and architecture at enterprise and system scope. In
essence, architecture work may be viewed as the translation of strategy
into designs that enable the organization to execute strategic intent,
achieving strategic outcomes through an adaptive combination of design
and emergence in the context of empowered and strategically aligned
Hm, as soon as I see the title, I want to work back in extemporaneous... you know, fractal and emergent begs the reflection choreographed and extemporaneous... but perhaps agility covers that well enough? [Note: not all emergence is due to extemporaneous actions.]
At any rate, would this be useful to get more of out there? For example, to help create a coherent way of thinking about the relationship between strategy and architecture at various levels in the organization.
These 17 minutes could change how you think about everything, but in particular change how you position your vision and architecture decisions: Dan Ariely: Are we in control of our own decisions? (TED), below:
This is an AWESOME video (heads-up comes via an Oscar Nierstrasz tweet) and I am totally put out that no-one pointed me to it a year or more ago!
Now do you believe me when I say that too often we canalize too early? Oh, and do please watch this [we need to check our (strongly held) intuitions]:
This also via Nierstrasz ("oh the irony"): '1984' Apple Mac Intro.
Best practices in application architecture -- must see! (via Udi Dahan)
Vision Statement: Locating Your Next Strategic Opportunity by Sean Gourley, HBR: The Magazine, March 2011.
And an illustration of the
"BMW has been extremely impressed with the potential of carbon fibre, so far. The company has been working with SGL on a type of injection-moulding process that can produce parts in minutes, and be handled mainly by robots. Parts can be bonded together or larger parts made as a single component. As the aerospace industry has already discovered, producing things with fewer parts greatly reduces the cost of assembly."
-- VW buys into BMW's carbon-fibre dream, The Economist, Mar 1st 2011
But, but, ... not relevant... what can we learn from cars? That's manufacturing. That's reproduction not development. And yet... Why did we go from objects to components to services? Raising the granularity of what we use/reuse across systems. Not at all the same thing as mass (re)production. But building systems out of proven larger grained subsystems (built out of proven large grained components built out of... you get the picture) is a path worth investigating. A different kind of assembly; cognitively challenging but less, if we can truly treat the elements as (black-box) subassemblies.
Ok, how about this:
"Each year, the FIA, the international motor sport’s governing body, sets new design rules in a bid to slow the cars down, so as to increase the amount of overtaking during a race—and thereby make the event more interesting to spectators and television viewers alike. The aim, of course, is to keep the admission and television fees rolling in. Over the course of a season, Formula One racing attracts a bigger audience around the world than any other sport.
Yet, each time the FIA mandates some draconian new rule change—whether the introduction of non-slick tyres, narrower aerodynamic wings or a smaller engine size—the leading teams have invariably trumped the restriction a few races into the season. And the cars fielded by the wealthier teams, which cost hundreds of millions of dollars to develop, are then going faster than ever. Once again, races become a tedious high-speed procession which, barring an accident or mechanical failure, all but guarantees that the pole-sitter (the fastest in qualifying) leads, lap after lap, to the chequered flag.
One of the few things your correspondent enjoys about such a technological sport as Formula One is that—while the design rules are explicit and rigorously enforced by the FIA’s scrutineers—the various racing teams tend to arrive at their solutions by different evolutionary paths. In the process, each car on the grid seems to inherit a unique set of characteristics (“phenotype” in evolutionary terms) derived from its maker’s traditional values and competences (its “genotype”, if you will)."
-- The Difference Engine: Darwin on the track, The Economist, Nov 19th 2010
There are so many lessons that article illustrates! Such as? The role of challenge and time pressure (and a sense that we can do something great here, because our competition is) when it comes to bursts of innovation. The role of analogy, including biological analogy, not just in communicating design, but as a source of already tested design ideas! The role of a well articulated architecture (in this case, based on a dominant design which is a de facto reference architecture) that enables frontiers to be pushed separately (engine and chassis) yet synergistically.
This from near the end of the same article:
Meanwhile, at Stanford University in California, John Koza has used genetic algorithms to devise analogue circuits that are so smart they infringe on patents awarded to human inventors. Dr Koza’s “invention machine” has even earned patents of its own—the first non-human inventor to do so.
-- The Difference Engine: Darwin on the track, The Economist, Nov 19th 2010
Craig pointed me to IASA's Architecture Foundation: Ramp-up your knowledge in 30 days reading program. Our Software Architecture: Central Concerns, Key Decisions paper is the capstone reading for the first week. (Thanks Miha; warm fuzzies felt here.)
I hadn't seen these particular pointers/references before:
3/2/11 Managing Debt: the New Frontier
The visual design wave of the 90's gave way to the Agile wave of the last decade. Now managing debt is catching some of the refracted limelight from (fr)agile. Hype engenders zeal. Many overdo and hit the wall. We course-correct.
I read two articles at the start of my day today:
Innocuous? Let me pull out a sentence from each:
"The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities."
-- Edsger W.Dijkstra, How do we tell truths that might hurt?
"Scientists have identified four new species of brain-controlling fungi that turn ants into zombies that do the parasite's bidding before it kills them."
-- Wayne Perry, What? Brain-controlling fungi and zombie ants?!
I feel like I just heard Macbeth's witches! I think I'll go back to bed! ;-)
3/3/11 More in the Vein of To Engineer or Not To Engineer
The "how do we tell truths" piece demonstrates that while computer science is a hard science, computer scientists could stand to learn something from the soft sciences. Which is the point, isn't it? Software engineering is about applying technology to address human needs -- it is about solving problems in the service of humans, (directly or indirectly) enhancing and enriching life for humans. So there is a cusp between humans and machines that we work at, and sure much of the machine facing work is hard science stuff. And the human facing work surely stands to benefit from the soft sciences. And somehow the twain must meet. Add to that the "small" matter of humans working together to create these systems, and...
It is has been a long time since I saw that letter do its rounds!
3/3/11 JD Meier -- Leaving More Than a Trace
In JD Meier's "moving on" post, he lists accomplishments from his 10 years as a PM in Microsoft's Patterns and Practices and that list is a well-organized trove of resources for architects! I'd pretty much seen all of it over the years, but never all pulled together like that. The body of work is awesome and inspiring and useful and impressive and ... really good stuff (my brain gets shy on lists)... THANK YOU JD!
So, Enterprise Strategy at Microsoft. That'll be interesting to watch through JD's blog window too! :-)
Aside: As treasure troves go, no one would characterize my journal that way (garr!) but I still bull-headedly work away at the Journal Map from time to time (when my self sense surges defiantly). I think in the end the map might help illuminate what I have been doing here, and help others appreciate it. I did say bull-headedly. I know, I don't do the hand-held version here. I don't believe everyone needs that; those that do, would not find this their suit. But our Action Guides will be great on the iPad.3/3/11 Alan Turing
The other day I was reading about Alan Turing and came across the British government's apology made in 2009. I hadn't known about that piece of Turing's history. Goodness, humanity can be so inhuman!
Thousands of people have come together to demand justice for Alan Turing and recognition of the appalling way he was treated. While Turing was dealt with under the law of the time and we can't put the clock back, his treatment was of course utterly unfair and I am pleased to have the chance to say how deeply sorry I and we all are for what happened to him ... So on behalf of the British government, and all those who live freely thanks to Alan's work I am very proud to say: we're sorry, you deserved so much better.
-- Prime Minister's Office. 10 September 2009.
Anyway, it was interesting to see that the latest PragPub has an article on Turing. It focuses on Turing's contribution to computer science.
Turing did more than make the leap that enabled our field to be created. In an important way, he was a martyr whose ultimate sacrifice should have brought attention (the precursor to change) to one of the most pervasive human rights issues of our age. He reminds us that even "straight" people are seriously bent; we all are, just in different ways. We're human! Diversity is an essential ingredient in propelling us forward technologically and culturally. Let's celebrate and encourage diversity in our field, not sweep it under the "undiscussable" rug like it's a dirty secret. If there's any shame here, it is on us!
I don't eat mammals as rule because I don't believe I am important enough to cause mammals to be killed for my consumption. Yet I manage to think it ok to eat poultry and fish. I'm a creature of convenient rationalizations! Imperfect. Absolutely. I strive to do what I believe is right, and I strive to figure out what I believe. And in the face of conflicting forces, I capitulate in some ways. It is all very personal, which is to say it has a lot to do with the accidents of my birth and of my life. Serendipity. Bliss. In capitals or small letters. The perhaps names of angels. We are all these bundles of good and evil, of amazing and tawdry, good and culpable. We strive to be more good. But we are fallible. Our best impulses and kindest intentions can wreak ill on another. Life's like that. Complex. And wonderful. And compromised. And glorious. Through the blessing of empathy, though, we can at least strive to be more kind. Through the blessing of gratitude we can celebrate the good in others and in ourselves.
Alan Turing was an inventor of computing. He was a national war hero.
And an emblematic hero in a cause to bring social justice to a big
sector of the world's people. I just didn't know about his role in that
last. Our field is so young and so full of exciting challenge, we can
forget to pay attention to our history.
The next open enrollment Software Architecture Workshops are as follows:
Enterprise Architecture Workshop:
This is really awe-inspiring: Gaudí’s Masterpiece
Barcelona scholar Joan Bassegoda Nonell notes, "Gaudí's famous phrase, 'originality is returning to the origin,' means that the origin of all things is nature, created by God." -- Gaudí’s Masterpiece, National Geographic
Well that does it -- I have to go to Spain! Dana has, but alas, not I. Yet.
3/4/11: And biomutualism (robotics engineers learning from biomimetics and biologists learning from the engineers): (TED) Robert Full: Learning from the gecko's tail.
Bio-mimicry isn't just about mechanical and chemical engineering; last month I pointed to a neat compilation of nature-inspired algorithms.
Image: slide from (TED) Robert Full: Learning from the gecko's tail
"It's not the lack of information. It's the lack of integration." -- Janine Benyus, TED
This project is interesting in its own right: Mapping sensory experience. And it sparked an idea. From time to time, working with architects who've needed help getting past apparent organizational roadblocks, we've done belief maps* just to raise awareness of how different stakeholders have different vantage points, beliefs and views on architecture and the initiative in question. I'd never thought to do any kind of experience map against the existing code base... Yet, couldn't we map our brownfield/legacy software this way? Well, it's an idea. You know, collect the emotive experience visually, as part of a pitch to "clear the backlog/debt," establish priorities and see where the biggest pain points are.
Ok, it sounds like child's play. But sometimes that's what it takes to get the undiscussables out from under the rug and just see things in a different light. (Note the disgusting smells, noise, congestion...) And the good news is, we can do this -- we don't have to be able to draw any better than 6 year olds!
You think that's too cute to try; you couldn't do that. Well, that's why you need a consultant**. To do the stuff you're not fool enough to venture to do.;-) Yes, it takes audacity. So? It's audacious to think we can do anything about the state of things when entropy is so persistent.
A map that focuses on the reactions and emotions the code base induces? What a concept! We map interactions among components, but our reactions to various parts of the system would be quite revealing. Of course running metrics and visualization tools against the code gives "objective/neutral" assessments of where complexity and coupling and so forth lie.. But the people living with system evolution have deep knowledge and attitudes towards the code that could be quite valuable to tap into and make visual, to help us build the case for "paying down the debt" and keeping it under control.
Ryan wants to do a research study on stress in middle school (compassion starts young). He inspires me to ask: Have you seen research studies on stress among developers related to the entropic state of the code base?
* We also do influence maps Of course, there's an xkcd for that.
** Those who have consultant-aversion have forgotten what consultants are for
-- smelling the bad smells the (management) team isn't smelling because they've
grown so used to the smells around them, and drawing attention to smells it
would be career-threatening to draw attention to if done from within. Well, we
do a bit more besides, but the smells stuff takes a unique kind of handling. And
we all know why plumbers are paid what they; who'd do that work otherwise? (For
the irony-impaired, I don't mean that is all consultants are good for. At
times like these, I'm very glad this is a quiet backwaters place!)
Image: From The Unstrung Harp, Edward Gorey
In The Unstrung Harp, Mr Earbrass is writing a book. As Serendipity goes, this evening I bounced from a retweeted heads-up (likening writing a book to writing software) to Neil Gaiman's All Books have Genders post. Serendipity? Well, you see Neil wrote Coraline, and had wanted Edward Gorey to illustrate it; the timing didn't work out, mainly because Gorey died. (Sorry, but I think Edward Gorey would have liked it to be phrased that way.) But it is more odd than that. You see I started my day reading The Unstrung Harp, and then stumbled on Neil Gaiman's account of his process writing American Gods.
In it he says:
"I don't know any creators of fictions who start writing with nothing but a blank page. (They may exist. I just haven't met any.) Mostly you have something. An image, or a character. And mostly you also have either a beginning, a middle or an end. Middles are good to have, because by the time you reach the middle you have a pretty good head of steam up; and ends are great. If you know how it ends, you can just start somewhere, aim, and begin to write (and, if you're lucky, it may even end where you were hoping to go).
There may be writers who have beginnings, middles and ends before they sit down to write. I am rarely of their number.
So there I was, four years ago, with only a beginning. And you need more than a beginning if you're going to start a book. If all you have is a beginning, then once you've written that beginning, you have nowhere to go."
-- Neil Gaiman, All Books have Genders
The heads-up on Edward Gorey comes via a Christoph Niemann tweet. I love Gorey's intelligent commentary/insights on life and, of course, resonate with his keen sense of irony. And whimsy. And as whimsy goes, Peter de Sève is one of my favorites -- this piece especially! Peter de Sève's A Sketchy Past is a lovely view of an artist's process, including the use of initial concept sketches (with cool mouse action to turn the pages in the preview). :-)
Uh sorry... a bit of whimsy serves me well when I need some light relief.
3/4/11 Stepping Outside Circles
At first I was somewhat stunned by the noise level (Indian myna birds in Durban came to mind) on Twitter, but then I realized that this is how we make the medium more vibrant. We assert our humanity into the strange globally connected mind-thing we've created, and it becomes a new kind of conversation where the "walls have ears" and sometimes talk back or spin the thread in a new direction, launching monologues and sometimes conversations down new corridors of influence. Like my journal (oh dear, really?), it can feel a bit like some folks left their drapes open while they changed their minds...
Seen that way... it is every bit as surreal as Alice in Wonderland!
Twitter provides an interesting mirror. As I've stumbled across folk that I
admire in the twitter-verse these past few weeks, I've followed them not because
I'm interested to know when and where they've landed physically, but rather
figuratively (what are they discovering in the mind-field out there?). Of those
I've followed, everyone with a high profile presence in software
architecture/design, with two notable exceptions, has followed back. On the
other hand, of those with a high profile presence in software/agile, only one
has followed me back (other than those already mentioned in the first
set/architecture). It is interesting to see the circles in our field, and how
little interest there often is outside those circles. (Oh, and "Programeter"
enjoys the notable distinction of being the
It is important to focus, so circles of focus and excellence aren't bad in of themselves, but they make "boundary spanners" important too. Architects are boundary spanners and connectors. Integrators in the broader sense of bringing others, ideas, and things together.
But, given the nature of these follow circles, I sure feel inhibited pushing out tweets... I did overcome that reticence with respect to JD, but that was for the record, not because I thought anyone who is listening in on my tweets would find the heads-up news.
Nobody who reads here needs my twitter updates (redundant). But if you prefer short form and reticent, you can use the "follow me" button below and save yourself scanning over journal entries. :-)
I'm definitely going to have to relegate Twitter to like a once a week thing! It's bad enough following my own Bliss, without adding a bunch of others' Bliss-alerts to my To Do stack attention deficit!
Image: by Sara B.
3/4/11 Models and Location
Arguing against MDD, Friedrich Steimann (Coding for the Code by Friedrich Steimann, Thomas Kühne, January 31, 2006) stated that "models have their greatest value for people who cannot program"... Isn't that throwing the baby out with the bath water? Sure, structured as a debate, the conversation pits extreme views (all MDD or none) -- which these "camps" tend to foster.
Whether we envisage MDD being dominant in the future of software, see it as one of the players in the landscape, or a passing fad, model-enabled development is clearly important, for just the reasons "Dr. Pro" (Kühne) points out:
"...graphical models excel in conveying static information: a two-dimensional layout of the structure of a system is much more easily understood than any linear form, in which links (the lines) need to be resolved symbolically. As far as the description of system dynamics, there is certainly no point in having an iconic equivalent of all the traditional features of today’s programming languages. Yet, surely there is value in expressing behavior in the form of interaction (sequence and collaboration types) and state diagrams."
-- Thomas Kühne, Coding for the Code by Friedrich Steimann, Thomas Kühne, January 31, 2006
Of course, factors like the granularity/degree of elaboration and precision of the models we use can have a lot to do with how helpful they are to development teams versus in automation. We only want to use models to the extent that they enable something importantly different than working in the medium of code does. That is to say, visual models that help humans reason about, and navigate around, complex systems can stop well short of what a generator may need. When connecting pre-existing subassemblies, we have yet a different set of opportunities and constraints. When modeling alternatives to investigate performance implications, we have yet a different set of goals and constraints in play.
Context factors, and we so often talk at cross-purposes because we ignore the importance of context. Software is needed is such vastly different spaces, with so many vectors along which to distinguish -- from brownfields to greenfields (or evolutionary to revolutionary, or mature to novel), from simple to complex, from one-off to small variations on a theme, from stand-alone to tightly integrated is systems (of systems), from enterprise applications to consumer products, etc.
Have you seen this modeled? (Other than this, or this! Randall's angels get with mine and connive, I'm sure of it. wink*) I think it would be useful to locate the base of different camps, and the perspective from that vantage point that makes their worldview make so much sense to camp insiders. But when you step into a different spot with different forces at play, a whole other set of considerations factor. So you get "agile" versus "agile at scale," for example. But you also get some form of gated or waterfall process still being predominant, and it is worth asking why, rather than shooting aghast arrows of derision at so antiquated a practice... (Remembering that for the software teams involved, waterfall may be more like cascades, like RUP or Evo, with just enough design upfront to do concept design and identify uncertainties, challenges and risks and associated strategies.)
[* I winked a clarifier lest your mischief detector is impaired. I so love the insight at the end of Dan Ariely's TED talk -- we accommodate for our physical shortcomings with steps and so forth; we need to become more aware of our cognitive and perceptual shortcomings and accommodate for those too. One of these is the perception of "connection' between events, when the connection has to do with perceptual filters. What we are paying attention to, shapes what we perceive and pay attention to. That said. Serendipity still plays a handy role! ;-) Ok, look, whatever angels are up to, I think they have better things to do than instigate Randall to draw cartoons that are only one translation away from the point I'm making. ;-) Of course, if an angel appears in Monday's xkcd...]
3/10/11: Ah, context factors modeled:
This motivates the need to contextualize:
In terms of positioning, there's also "context is king" in the 97 Things book.
Referring to Contextualizing Agile Software Development: I don't know how it affects the octopus... but I think at the project level, dependencies outside of the project are a critical shaping force. For example, an embedded software project has dependencies on other engineering disciplines. In a product family situation, a product team may have dependencies on a product platform (shared product framework) team.
3/11/11: Ah, Scott Ambler's context framework is here: The Agile Scaling Model (ASM): Adapting Agile Methods for Complex Environments
I redrew that for Dana showing him how simple it is to draw the elephant with the hindquarters and add the ears... then add the "damage"... and the architect doing damage control... It makes for an easy visual, a (cheap?) laugh, and an important point. If you're constantly doing damage control, you can't get out front to lead away from the persistent mess state.
Ok, that's freaky. ;-) I wanted to link to the "shoe lace" lead point I made in a post month's ago. Guess what the post is titled? What We're Paying Attention To. (The anecdote is 3rd paragraph after the first photo.)
3/4/11: Note to self: I must remember to look in on Mylyn (Eclipse) when it releases in June.
Here's a great post by Doug Newdick from New Zealand: Creating A Conceptual Architecture. It really is a wonderfully written overview of Conceptual Architecture.
Well done; thanks Doug! Now I'm in a quandary. Twettiquette would be to "pay the tweet forward" but that's "horn tootin" that Q<='s tend not to like to do. And in case you hadn't noticed (ha!), I'm one of those. Well, at the very least, I'll put a link to the post on the Bredemeyer site.
(And, being a curious sort, that introduced me to Doug's personal blog. It is neat to encounter so interesting an adventurer! And his 2 year old will like Christoph Niemann's Subway and That's How. As kid's train fetish's go, there are important lessons for parental enablers ready to hand. Ryan, now 12, is still singing about trains -- here's Ryan (and Dana) singing Wabash Cannonball♫ (recorded and produced by Ryan). This version with train pics. Don't worry. It doesn't always last that long.)
We've been thinking about New Zealand a lot since the earthquake that so devastated Christchurch.
Aside: Not much time for distraction or work today, what with a full house, the kids' music recital this morning and Faust tonight. I hear tell that Andrew Lunsford has a voice and range that puts him in the same sentence as Pavarotti.
3/6/11: Train + New Zealand-related:
Not an angel, but hey, it uses the "attention" word. Now do you really think that could be accidental? ;-)
Following up on Impromtu, I read the wikipedia treatment of Chopin. This, in the footnotes, caught my eye:
"Chopin would always feel twice exiled—from his country and from his language. Imprisoned by foreign words, the expressive power of his music unbound him." 12, Chopin, wikipedia
Early, Chopin showed talent in art, in prose, and in music. But by being shut off from his expressiveness in words, he channeled all that creative genius into music. His is a great example of that "look what I did with what life did to me." He used living, the torments and the passion, being cast suddenly into making a new life, the cloistering of his illness, etc., to be highly innovative and creative, breaking with convention and precedent, making of himself his own distinct person and music.
Architecture -- decisions -- constrain. But these "canals," these constrained spaces, also enable. A vast open canvas of possibility can leave us "wandering in the desert" (Dana's phrase) without a compass and a destination.
3/7/11 To Err is Human
This reference to Kathryn Shulz's book Being Wrong (quoted by Tim Kastelle here) caught my eye:
'In our collective imagination, error is associated not just with shame and stupidity, but also with ignorance, indolence, psychopathology, and moral degeneracy. This set of associations was nicely summed up by the Italian cognitive scientist Massimo Piattelli-Palmarini, who noted that we err because of (among other things) “inattention, distraction, lack of interest, poor preparation, genuine stupidity, timidity, braggadocio, emotional imbalance,… ideological, racial, social or chauvinistic prejudices, as well as aggressive or prevaricatory instincts.” In this rather despairing view – and it is a common one – our errors are evidence of our gravest social, intellectual, and moral failings. Of all the things we are wrong about, this idea of error might well top the list. It is our meta-mistake: we are wrong about what it means to be wrong. Far from being a sing of intellectual inferiority, the capacity to err is crucial to human cognition. … Thanks to error, we can revise our understanding of ourselves and amend our ideas about the world.'
Unfortunately Kathryn Shulz seems to be right about a lot (how will she learn?), but not about that dishwasher thing! I'm sorry, but in my family the only thing the rest of 'em get right about loading the dishwasher is doing it -- at all. They haven't made the experimental study of it that I have! They think it is just a thing you dump dishes into any which way, not something you work at with great intentionality and forethought, playing configurations over in your mind and trying the best of them out, so that you develop the heuristics that allow you to get the maximum load every time.
I read that last paragraph to Dana and ... let's just say the laugh was heart healthy. :-)
3/7/11 Form Follows Function
"Using false-colour techniques, Dave McCarthy and Annie Cavanagh draw out the detail of a honeybee's anatomy, highlighting its fluffy thorax and the difference between its three pairs of legs, which vary in shape according to their function."
-- Kat Austen, Colour me beautiful: Wellcome Image Awards winners, NewScientist, February 2011
The image of the bee is lovely! Well, form and function should be intimate with one another. The point is that, as nature teaches us, form should be in harmony with the functions it enables. In evolving systems, functions cause adaptations adjusting form to fit function; form enables and constrains functions so functions are adapted to and by form.
So design of form and function should be intimate, influencing one another. Not form follows function -- that is, not form after function.
Responding to a question about guiding principles for EA, I mentioned the Architecture Principles page on the Bredemeyer site, as well as our Principles for Architects page (you know, describing the Minimalist, With Teeth and Connect-the-Dots principles). Which caused me to think again about principles and I went back and added clarifying commentary to my earlier post on principles. If you're interested in Architecture Principles, please do read that post (and its extension) and let me know if it works and what questions arise.
Of course, guiding principles for enterprise architects are more like the second (Principles for Architects), and less like the first (Architecture Principles), though clearly there is overlap. They accrete in the space enterprise architects are paying attention to and being guided by, rather than the space they're requiring others to pay attention to. ;-)
This looks like an example more along the lines of guiding principles:
What we call these things, and how we treat them, is going to have something to do with whether they are going to be part of our architecture (formally), and hence under governance. In other words, do teams have to motivate (and even formally request an exception) their decisions when they run counter to the principle, or is it something they can treat as simply a guideline? If the latter, perhaps we'll just call it that -- a guideline.
3/8/11 Conversations that Clarify
The comments on Doug Newdick's Conceptual Architecture post point to improvements that need to be made to the presentation of Conceptual Architecture on the Bredemeyer site. :-) Images indeed -- I'll get right on that (in the morning)! It might be worth stating again that what is in VAP is emergent and adapted, not "unprecedented invention":
"For the first few years, we balked at giving VAP a name, because to us it is just what architects do, organically scaling up and down with the organizational and system complexity and state of maturity (or lessening degrees of freedom) of the system. Then we found clients calling it the "Bredemeyer Process" and we balked still more at that, so called it Visual Architecting to place an emphasis on the visual (integral to the collaboration, conceptualization and communication inherent in designing systems to be built with and through the empowered contribution of many minds -- and impacted by the whole person that houses that mind). The key has always been that architects have an enabling toolkit (along with models that organize, but by no means dictate, the decisions, views and threads of reasoning), but architects decide what is architecturally significant for their system, and how to go about addressing only what is, to the extent necessitated by a commitment to realizing strategic system outcomes." -- moi, 1/4/11 (see also moi, 7/28/07)
For example, responsibilities derives from CRC cards (class-responsibility-collaborator cards from Kent Beck and Ward Cunningham, and related to responsibility-driven design work of Rebecca Wirfs-Brock), but we applied the template (also used in the Buschmann et al Architectural Patterns book but we were doing this before that was published) to architectural elements/components and added rationale -- hence CRC-R. That was back in the mid-90's. More recently, documenting the rationale for architectural decisions has become a point of emphasis more generally in the community, but we banged that drum from the first.
Now I should mention, we use those lists of component responsibilities to factor and refactor, coming up with different design alternatives, assessing cohesion and resilience of the design to changes in response to different forces. This makes conceptual architecture a very powerful part of our "experiment on the cheap" toolkit, because we can play out different approaches cheaply -- with sketchy models and informal lists of responsibilities. Looking across the responsibilities, we can evaluate cohesion, we assess balance and coupling, so that we create crisp abstractions. We posit responsibilities, and then use interactions diagrams (just sketchy, early on) to explore behavior and discover responsibilities, and revisit the factoring. We're giving the system early shape, focusing on model-storming alternative approaches.
And as Benjamin Carlisle points out, by talking through this conceptual model with non-technical stakeholders, they can play a role in validating fitness to purpose and uncovering opportunities/unstated requirements or intentions, desires and expectations. It is surprising how often make-or-break big things are surfaced through the aid of so simple a diagram, just because fresh perspective, new questions, looking from a different vantage point, assessing alternatives, etc. all become possible.
It is also a great vehicle for navigating the system, assessing the impact of new features, for thinking about the team structure (Conway's Law), etc.
It is a thinking/experimenting aid, providing the means to reason about the system and alternative approaches (yes, we may -- nay, will -- need to dive down into details in some areas, etc.). We're thinking about "large rocks" and large rocks are costly to change as more and more of the system is built out. And they're a communication aid, enabling conversations with stakeholders who might not have perceived they could contribute or be interested -- important because at this level, if something is missing or misunderstood or a better way to do it emerges, the impact is strategic! And a navigation aid -- important in large systems.
I'm repeating myself. It's -- gulp -- almost 2am... always too much to do in a day!
Aside: I do want to hasten to add that in all of my work, I do encourage suggestions and different perspectives, approaches and ideas -- the acknowledgments in our Cutter papers (e.g., The Art of Change: Fractal and Emergent) will give you a window on that process. I just prefer it to be personal, because conversations (f2f, email, IM or skype) are so important to pushing ideas along, but collaborative conversations are founded on, and develop, trust and respect. I understand the need for and value community conversation, but I also know that my personal style is gentle and combative approaches just crash my systems. So in the interests of journaling my exploration in public, I offer a compromise. Which is to say feel free to contact me () if you want to collaboratively push some conception around and extend the boundaries of my thinking, share resources with peer architects, etc. Where you permit, what I learn from those conversations will be reflected here (with attribution) as I'm very committed to sharing my teachers and influencers as best I can. That said, after successive attributions, if the concept sufficiently enters my mental model I may start to use a concept or technique without attribution -- for example, I've used and attributed "bliss-following" to Grady Booch (who attributes it to Joseph Campbell) but I don't do so any more because that'd be seriously old for people who read along here regularly. That said, if it became clear that a place to converse was desired and would be used to further my and the community's conceptual toolkit, I would be happy to make my blog more active.
3/17/11: Motivation for refactoring during architecting: What could go wrong?
We have renamed the "validation" aspect of VAP iterations to "improve/validate" and that hasn't worked its way through all the models and images. The burden of legacy...sigh. :-)
Which leads me to...
In Deliberate Discovery, Dan North talks about "axes of ignorance." If you're familiar with VAP, you'll recognize that "axes of ignorance" just maps to our "uncertainties, challenges and risks" (on our architecture dashboard) that we use to direct attention when we ask that orienting question "what, at this extraordinary moment, is the most important thing I should do today" (Bucky Fuller). The difference is that we advocate learning with the cheapest medium that will serve. If we can learn with an exercise of the imagination, with a (sketchy) model, with role play, with a (paper) mock-up, with something analogous, with a focused prototype (call it a spike if you want), then we do that. And we do it bringing in other stakeholders (another conversation we need to have) into an "improve/validate" session -- early we focus on "failing" (fast, cheap, small -- to save us from failing big, at great cost). Which is to say, success is finding stuff we're doing wrong or could stand to do differently and in some sense better.
It is worth pointing out that the uncertainties may have to do with the market, the system concept and which capabilities will create strategic advantage, or with technology and how we will build the capabilities. We're designing that form and function that will be in harmony with its (various) context(s) and within itself. Various contexts -- of use, and development, evolution, operation, etc.
Some discussions of VAP:
I know, I know, the book is long overdue. But it will be a different book than it could have been even 6 years ago. In the meantime, the map of this journal is by no means complete, but it is a growing survey of the landscape.
3/27/11: The architect as leader has to discern which "oh crap" moments need to be addressed and how, keeping the team's focus on the energizing vision and the compelling need so that "black hat" nay-sayers don't damp the optimism and enthusiasm of the team, and helping everyone stay positive about the averted point of failure inherent in that moment of sinking feeling that opens up to finding a better approach. Architects need to be resilient and enthusiastic.
When I mention resilience, I think I will forever more remember Garr Reynolds
(who lives in Japan) post on that topic: fall down seven times, get up eight. Barely a day goes by that I don't sob
for the people in NE Japan. My heart breaks with their broken hearts, but they
do also lift my spirit with their dignity and grace.
Via a Kent Beck tweet:
“The metaphor is perhaps one of man's most fruitful potentialities. Its efficacy verges on magic, and it seems a tool for creation which God forgot inside one of His creatures when He made him.” -- Jose Ortega y Gasset (Spanish philosopher and humanist , 1883-1955)
Metaphors in design:
If you haven't read our Getting Past ‘But’ paper, or haven't read it in a while, I'm going to suggest you at least read page 6-10. I just reread that because I'd recommended it to someone and then felt self-conscious at the audacity. Rereading it, I'm reminded why I so love that story. In three short chapters (or 5 pages in my recounting and debrief), it covers what whole books on innovation and leadership tackle but without the charm. It has the tastiest insights, like:
"But we’ll think better each on his own stoop, because often thinking gets lost in talking." -- Meindert de Jong, The Wheel on the School
I guess now I need to create entries on symbol and (visual) analogy. And... all this:
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.
As for that Impressions post -- I laughed out loud at the two sentences and links below the stone pictures. Who's been writing in this journal anyway?
The "have a point of view" meme has emerged in the design community (articulated by Diego Rodriguez here and here), and it relates to what I've been saying about developing a strong and unique individual aesthetic because that is what creates distinguishing system integrity in system design. It occurred to me, watching Doug Hofstadter's presentation Analogy as the Core of Cognition, that what I'm getting at is developing "design fiber" which is like moral fiber but in a system design sense. It is your design compass, if you like. Analogous to a moral compass, and with strong elements of your moral compass built into it.
Remember this: On the Criteria To Be Used in Decomposing Systems into Modules, D.L. Parnas, Carnegie-Mellon University, Reprinted from Communications of the ACM, Vol. 15, No. 12, December 1972? In it, Parnas demonstrates developing architectural alternatives where the architectural elements (components, modules, ...) have different configurations of responsibilities and interfaces, and assessing them with respect to key forces or strains that the system will be subjected to -- like design changes. And team organization and work allocation.
One of the many things that Parnas understood and positioned astutely (way back when), was the importance of context:
"This is a small system. Except under extreme circumstances (huge data base, no supporting software), such a system could be produced by a good programmer within a week or two. Consequently, none of the difficulties motivating modular programming are important for this system."
-- D.L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972
I watched Doug Hofstadter's presentation Analogy as the Core of Cognition. Some notes:
This echoes what I took away from Hofstadter's talk:
"Categorisation is a basic feature of life No creature, however primitive, can survive very long unless it can deal with issues such as: 'Is this the kind of situation where I eat this, escape from it, mate with it, look after it, ignore it … ?'. Since situations don't come with neat labels that say 'Eat me!' or 'Escape from me!', this implies some kind of pattern recognition, and hence some kind of comparison: 'Is this new situation that is emerging just now more like an 'edible' situation, like a 'dangerous' situation …' or whatever."
3/10/11 Sketchy Iterations Early
In architecting, we posit high level structural concepts, and explore what would be needed to give them the "essence" we envisage (top-down). And we consider more fine grained concepts or conceptual entities or abstractions, and build up higher level abstractions (middle-up). I liked Hofstadter's way of talking about building up more abstract concepts: glomming concepts together and putting a membrane around them, and treating that as a concept that hides its internals (though they are semi-visible or visible if we look inside the membrane).
We do this elaboration and abstraction in diagrams (informal models where we use UML but without being pedantic or complete), quick and sketchily -- so that we can experiment with different constructs, different abstractions and arrangements of responsibilities and explore different interactions to achieve system outcomes and enable stakeholder intentions (and relieve stakeholder frustrations) and eagerly, diligently, enthusiastically and quickly go after "oh crap"* moments -- and what if and what else and why not moments. We're going to learn, to revise and refactor, even redo. Our orientation is to explore where we need to, to resolve dominant uncertainties that must be faced early in the cheapest, fastest medium that will get the job done (adequately). Where we can, we work quick and dirty. We're imagineering -- if we can get a better sense of opportunity or approach doing more imagine than engineer, we do some of that.
Not forever! Just to get a sense of the lay of the land and where promise lies, so we can build something to test out that promise more concretely. And we work iteratively and incrementally. Quick and dirty with models, and with code. And as we build out the system, we need the architect to be paying attention to system integrity -- helping and guiding the team in evolving the structure and ensuring structural integrity, but also actively discerning what will compromise or threaten structural integrity. That is, the architect has system oversight, ensuring system properties and capabilities. And the architect looks ahead and peripherally to assess what market and technological forces the system will be subject to, so that the system is shaped dynamically and sufficiently proactively.
* Hey, I might have sunk 60 degrees in your estimation, but I've risen 80 in my son's for using Dan North's toilet talk. ;-) At least I'm pleasing someone!! That's something. [Still, I think I'm going to have to start calling them "oh rats" moments instead.]
3/16/11: It is perhaps worth noting that how fuzzy the front end is, depends of what we're exploring and designing. Redefining a business or searching for opportunities to build new products around is different than exploring the feature set of a derivative product within a well-understood product set that the business and its customers/users have strong expectations around. And that can box us in, to a fault. It is generally more difficult in the case of an extant product set to get and spend any time thinking about the broader ecosystem and technology directions and new possibilities, but that is why those evolving extant products fall into the me-too trap of looking too much at competitors playing the same "next logical step" game. Continuing to differentiate is a matter finding unmet aspirations, emerging intentions as users find new things to do with the product, resolving frustrations and so forth. It continues to be a matter of creatively understanding the context and emerging opportunity (because something new becomes possible, or because we or users start to find new applications or ways of thinking about the system). Expectations are continually being reshaped by what happens in neighboring domains, so new intentions and aspirations, on the positive side, and frustrations on the negative side, emerge. We need to look at what else is happening at the edge and beyond the radar of the team once it gets into build and ship mode. Companies in neighboring markets, sometimes even those we don't think of as "neighboring" may be eyeing our market (as in the case of Apple entering the smartphone market with a phone+internet extension to an iTunes device).
3/10/11 Heeling Ourselves
Thomas Jay's alter ego posted a provocative (in the best way) call to take a fresh look at applying some of what our field enables to itself. That, of course, is close to my mind/heart. So, I'm interested to know more. For example, what points does Brian make if I select this ending:
"...one of which explores the idea that one source of our perception of muddiness is the primitive tools and representations we currently employ to navigate and visualize our codebases." -- Brian Foote
And I like the open-to-other conclusions ending to that post. :-)
(You know my position on cartoons. Here's one about parts and relationships. And timelines. And visualization. And you know my position on "cartoons." Well, I did playfully suggest this... All in the interest of being playful -- opening people up to change -- and not taking oneself too terribly seriously.)
As for "heeling ourselves" this from Gregor Hohpe:
Applying our craft to our trade, visualization is an obvious area. We're doing so much to visualize, analyze and dashboard business operational and competitive intelligence, and system health monitoring has been getting more attention. Design simulation. to assess and improve designs is a less tapped area and the PPOOA work on model-based performance evaluation is worth looking into if you're architecting real-time systems.
3/10/11 Quacks Like ...?
Screenshots from Glenn Vanderburg's Real Software Engineering presentation:
Images: Screenshots from Glenn Vanderburg's Real Software Engineering presentation where he's quoting from an early NATO paper
The "software engineering doesn't work" title is provocative -- yes, we need to do better! But clearly we've done a lot right. Just look at how much software threads and buoys our lives and businesses! Yes, we miss schedules. What complex creative endeavor has a stellar record there? Consider the Dreamliner! And Boeing isn't alone. And delays where software is implicated may still be externally induced -- consider the Hyundai Sonata Hybrid. Yes, there are software glitches. But mechanical parts drive recalls too. So, yeah, we and other engineering disciplines need to get better, but "doesn't work" is ... more dramatic than "lots of room for improvement" and that is the point. I think it is worth remembering that development (system development, product development, application development) is in the space of creating something new or evolving it.
Well... draw your own conclusions. (Hint: context factors.)
3/11/11 Safety-Critical Systems and FTA
3/11/11 Supergeeks and Waterfalls
This article (via Chris) is worth a read, I think: Killing Bono. It is a vivid story that culminates with insights like this:
"We all fictionalise ourselves in the process of creating a story out of the raw materials of our life. For some it is a soap opera, for others an epic, but, for all of us, it’s an ongoing narrative that we constantly manipulate and reshape, improving (like the best anecdotes) in the retelling. This is not just true of writers. The story is one of the key ways we define and order our experiences as human beings: how we tell ourselves and others who we are. And our stories are full of omission and exaggeration, the stuff of subjective experience."
-- Neil McCormick, Killing Bono
Here's a line to downsize our kind:
"It’s OK, he’s playing you as a kind of supergeek. That should be enough to put people off.”
And you wonder why waterfall/division of labor still dominates? We put people off! :-)
3/12/11: We put people off? Well, that sounds extreme, but there is something to that, and it frankly took me by surprise. Because we actively champion the inclusion of architects early -- in relevant pools of strategy and system conception -- we hear the perspective of product and strategic managers who want to shield their non-technical people from dismissive techchismo during the ambiguous and uncertain discovery that characterizes strategy formulation. I have spent the best part of the last two decades working with software architects who are enthusiastic, creative, open, playful, and it took the wind out of my sails to get this push-back. Somehow a real or a projected experience has created the expectation that we'll make an assessment (simplistically), assert what should be done, and disparage anyone who ventures an alternative point of view. It occurred to me that for some technologists who are really master of their craft but out of their zone of mastery in the ambiguous, uncertain fuzzy front-end, this discomfort can cause disengagement or defensive assertiveness, surfacing as impatience to get on with it and do something. Developing code, we focus on bringing problems under control, not letting them free-associate into big buzzing uncertainty. This is not to excuse what comes across as hurtful dominating and belittling behaviors, but it does help us to understand them.
I don't believe that this should push us away from inclusion of technologists in system conception and strategy exploration and system design, protecting business users and customers from "elitist arrogantly dismissive software folk who speak a tech-ese that is far from business reality." But it is one of those undiscussables that impede concurrent development (with multi-functional/cross-disciplinary teams). It is a case of "I have seen the elephant in the room, and he is we." At least, he is who we are perceived to be. So the stereotypes further entrench themselves. Technologists conclude the business is clueless (because they aren't informed by technology capabilities and limitations and opportunities and directions) and the business thinks technologists are only good for executing to a narrowly defined plan. When we get locked in these perceptual camps, we don't get the opportunity to break the mold. It takes trust and positive expectations to get out of this cycle.
Now an important dimension of this discussion of work divided by specialty is that in complex cognitive domains, specialization is crucial. There is just too much to know for one brain to hold it all and act on it. However, for innovation, connections need to be made across specialty areas. Mastery tends to drive a narrowing of focus that creates a frame of reference from which it is hard to see other points of view.
"... experts tend on the whole to form very rigid camps, that within these camps a dominant perspective emerges that often silences opposition, that experts move with the prevailing winds often hero-worshipping their own gurus..."
-- Noreena Hertz: How to use experts -- and when not to, TED London, 2010
Our education systems, our work experience, so much drives us in the direction of specializing in a functional discipline. A person who is credible, conversant and productive in both software development and strategy exploration has a vital role to play, developing a special kind of mastery -- that of system thinking and design (making it possible to make things more the way we want them to be). So the people who are effective at bringing divergent, diverse perspectives from different disciplines together to bring about differentiating innovations are to be treasured. Not at the expense of the masters of specialty focus, but in addition to them.
"Fragmentation is a condition in which the stakeholders in a situation see themselves as more separate than united. The fragmented pieces are, in essence, the perspectives, understandings and intentions of the collaborators, all of whom are convinced that their version of the problem is correct. As we approach the end of the first decade of the new millennium, it is clear that the forces of fragmentation are increasing, challenging our ability to create coherence, and causing more and more projects to flounder and fail. The antidote to fragmentation is shared understanding and shared commitment." -- Jeff Conklin, p.18
Consequently, we need to foster mastery and contribution (essential to motivation, which for smart people is hard to tease apart from personal happiness or joy in work) and much more organically bring diverse perspectives and contributions together to address the wicked problems of system conception and design. We need a more organic notion of process (where process amounts to activities and how we communicate and co-ordinate them to achieve desired outcomes). By organic, I mean it acts like an organism, responding and adapting to environmental conditions, state, and intent.
Conception of a system is part re-conception of the ecosystem it will shape and be shaped by. We're think about the value network and about the system, shaping both the form and function of the system as it shapes and is shaped by the ecosystem (as it touches and interacts with, hosts and gets value from the system).
"Studying one blade is not enough; it takes both for the scissors to cut." -- Herbert Simon
Thus system design is not an only-technical activity (the software design view), though if we move away from the notion that design is just skin-deep, then design is not a-technical either.
“Designers create two things: the problem
space and the solution space. As they engage with a problem, they are
continuously redefining what the problem is, and what the solution is.” – Lucy Kimball
"Organizations are beginning to embrace the idea that these two aspects of projects – problem understanding and solution formulation – are not distinct phases, but rather different kinds of conversations that must be woven together from beginning to end. ... At the heart of this new understanding of organizational life is the recognition that project work is fundamentally social, and that communication among stakeholders must be managed and nurtured in order for the social network to cohere into a functioning entity. What is missing from our ‘social network tool kit’ is an environment or ‘container’ in which stakeholders can collectively step back to see the big picture."
"What Rittel said is, it’s just not that
easy. Problem understanding is actually the more important and evasive part of
the process." -- Jeff Conklin, p.18
Image source: Six Characteristics of Wicked problems, Jeff Conklin (interviewed by Karen Christensen), Building a Shared Understanding of Wicked Problems, Rothman Magazine, Winter 2009, p. 19
Many who advocate agile, stop at point number 1... By quickly getting more potential solutions on table and exploring them in quick mock-up form, we eliminate some of the worse options (one of which might have been built, if we stopped at 1 and just built the first thing we thought about). This presentation (by Steven Blank) positions an approach that is along the lines of the VAP approach (just pictured on the Strategy Canvas -- I need to draw how that maps to our Visual Strategy map, so you can see the relationship/simple reconfiguration).
3/13/11: I wrote the piece above yesterday, then read the interview with Jeff Conklin today, and the two are very complementary so I wove some of the points Conklin made into the piece to underscore points I was making. I do recommend reading that interview with Conklin. Of course, you'll recognize that it motivates VAP. :-) No, not in so many words, but VAP is that iterative concurrent multifunction shared understanding creating process. Now its time to (re)read Getting Past ‘But’. :-)
The full reference is: Jeff Conklin (interviewed by Karen Christensen), Building a Shared Understanding of Wicked Problems, Rothman Magazine, Winter 2009, p. 17-20
Design is about choices. It can be implicit and ad hoc, choices being made without much consideration given to finding and evaluating alternatives. Or it can be about more intentionally surfacing alternatives and making choices. The latter is a matter of degree. We can try to uncover every uncertainty and challenge and risk and exhaustively find alternatives and the decision space quickly explodes. Or we can adopt a more organic approach that addresses dominant make-or-break uncertainties and challenges early, and continually seeks out what is make-or-break in an iterative and incremental, evolutionary approach that is tested and adjusted -- but more so early, and as cheaply and quickly as can effectively clarify the direction to take.
"As organizations think about architects, it is becoming less about technical expertise and situations where you slide requirements and pizza under the door, waiting for great solutions to pop out. It is looking at the softer side of how people, businesses and industries work together and the kinds of support required to be successful."
-- Charlie Bess, The enterprise architect’s role in our dynamic business world, 3/14/11
3/11/11 Firefox 4
"Mozilla has announced the first Firefox 4 release candidate, after eight months of beta testing on the latest version of its open source browser. ... According to Mozilla, it has fixed more than 8,000 bugs since the first beta was released in July of last year."
-- Cade Metz, Mozilla delivers first Firefox 4 release candidate: 8 months and 8,000 bugs later..., 3/10/11
"Insight comes from experience and emergence." -- Brian Foote, tweet 3/12/11
And insight comes from new connections, a change in perspective, and so forth. In short, insight may arise out of collaborations, which cause new connections to be made.
What we do in the exploratory early phases in VAP, is playfully make new connections possible, so we get those "ah has" from connections and fresh perspective and imaginative leaps, etc., and "oh rats" moments from discovering uncertainties or challenges or flaws, etc.
3/13/11 Difficult Conversations
There's an expression "if you wrestle with a pig -- you get dirty and the pig likes it" (attributed to George Bernard Shaw) that serves as a reminder not to engage in factious argumentative positioneering that drives rifts.
There's also a book:
At the same time, differences of opinion, divergent points of view, different backgrounds and perspectives, are very important to making new connections and finding/solving problems, the heart of innovating:
Being inclusive of different viewpoints, means being inclusive of different styles.
Conversations of a different type:
3/13/11 Just Keeping Track
3/13/11 EA Innovation Idea -- Inside Angels
3/13/11 Google Circles
"Everything users share on Circles will be shared only with the most appropriate circle of social contacts in their lives, not with all your contacts in bulk. ... It's hard to think of a stronger angle to take than support for contextual integrity of communication and conversation, of personas in social networking."
-- Mashall Kirkpatrick, Google to Launch Major New Social Network Called Circles, Possibly Today (Updated), March 13, 2011
The trouble with being late to the party though, is that it is all about networks already in place on the competing social platforms. Not only is there set-up cost to networks that would have to be borne again, but there is the density of networks and relationships already in place on the popular platforms. Making the switch has to overcome not just general inertia, but the ties into extant networks.
3/13/11 Software Complexity
How many LOC does it take to run ☼baggage handling at Schiphol airport? 3 million!
"What 3 million lines of code means to a piece of luggage... It means Amsterdam Airport Schiphol will be able to accurately and efficiently move 70 million pieces of luggage per year—20 million more bags per year than they used to. The airport's automated baggage solution will allow Schiphol to increase their baggage handling capacity by 40 percent, so they can meet the growing demand placed on them as one of Europe's largest transport hubs. This system is built on IBM Rational® and Tivoli® software and runs on Power Systems™. A smarter business is built on smarter software, systems and services." -- IBM
The scenes of devastation and loss in northern Japan are mind-blowingly chilling and saddening. The scope of wrecked lives and livelihoods comes across in the pictures and stories; my mind freezes and thrashes intermittently, just unable to even conceive and deal with it! The shock and pain transmits through our shared humanity.
Image source: Japan Surveys the Damage, Wall Street Journal, March 13, 2011
3/16/11: To follow the still unfolding disaster and distress: MIT NSE has informative updates, The Guardian (UK) seems to do a good job of reporting straight talk, the Lede blog on NYT can be slow to load...
3/16/11: Tech Helps!
“The responsibility of architecture is the architecture of responsibility.” -- Jan van Til
This contragram applies well to our approach: the responsibility of architecture is to assign, structure, interrelate and co-ordinate responsibilities to achieve system outcomes (the architecture of responsibility).
Historically our industry has tended to suppose there is/should be a linear progression from context and intentions to system capabilities to shaping responsibilities to building the system (we called it waterfall). However, values like empowerment and a willingness to explore and adapt are part of the (organizational) context and will draw us to a less hierarchical, less linear process. Moreover, intentions would generally establish how we will achieve sustainability (at least economically, but hopefully also socially, technically, environmentally, and personally) and differentiation through innovation (in product or process). We can assert intentions unilaterally, but the more we lean to empowerment and agility (in the sense of adaptability and responsiveness) the more we lean to developing intentions-capabilities-responsibilities collaboratively and adaptively through multi-functional teaming and iterative exploration and convergence that begins with building models of the system and quickly moves to adaptively building out the system. When we do so taking an adaptive, agile approach, we're probing the design and implementation for fit to purpose and context as well as testing and improving structural integrity.
Some reminders come to mind:
The discussion thread that gave rise to the contragram is interesting in its own right:
This is a useful add to the social responsibility line of thinking Tom Graves stimulates:
While the contragram is a stimulant to discussion in the EA and systems and software architecture space, I think the bigger question/discussion of social responsibility and behaving in socially and environmentally sustaining ways (which causes us to question rights to "having") is critical, and finding ways to incent organizations and individuals accordingly is important. These are all social constructs. That's good, 'cos unlike tsunamis, we can change them. If we have the collective will to. In The Art of Change: Fractal and Emergent I pointed out that technical debt is a special case of opportunity debt. But really both are examples of moral hazard. We still seem to be able to rationalize and turn a blind eye to moral hazard, but the ☼rumblings of discontent are getting louder as more people educate themselves. There is a growing sense that we need to see organizational and environmental ecologies and personal well-being as intimately and intricately interconnected.
This is an interesting article on changing minds to change how we do things:
3/14/11 Architecture (Again)
In talking about software visualization, I've distinguished architecture as intention from architecture as reflection of a built system (playfully calling these smoke and mirrors; Grady Booch in turn wrote about "architecture as shared hallucination").
Kris Meukens put this usefully and simply:
I agree, it is useful to make these distinctions, and for reinforcement, I'll just rephrase this in the terms I tend to use:
This last being the starting point for intentional design of evolutionary increments and adaptations in response to (emergent) opportunity or to make the system more resilient, scalable, etc. (Kris's diagram makes this clear; useful visualization!)
To continue the conversation, then: when we're talking about the architecture of dynamic systems (including socio-technical organizational systems and software systems), we're designing and reflecting on system dynamics. Yes, this influences and is influenced by our design of the structure. And it is an important facet to consider as we understand/represent the design of a built system so we can reason about evolving it.
Side note: You'll notice I used the word architecting instead of using architecture as a verb. We have, on occasion, been taken to task for inventing the word and while I'm happy to indulge in neologism where it serves, I/we are not responsible for "architecting" and indeed it predates the use of the word architecture in the field of software or enterprise design.
3/14/11 A Failing of Common Sense?
Does anyone think that failing in the sense of market failures and associated retrenchment is good? The point about emphasizing "failing" (fast and cheap) is to learn so we avoid the big failures that cost jobs and happiness! Now I think it is valuable to put a positive spin on things, so instead of saying that we're "failing" we can say that we're "learning." And in that, Edison's reaction to losing a good deal of his work in a fire serves as a great example (right).
"A crisis is a terrible thing to waste." — Paul Romer
Yet... if we could cause many of those failures to surface earlier, when less is vested, wouldn't that be better?
I have found that when I tell architects "ok, now we're going to switch gears and success during 'improve/validate' is finding all the ways we're headed off a cliff," then they really get down to finding gaps in understanding and omissions and uncertainties and things we could do better or need to understand better or resolve in some way. It helps to step beyond our protective egos and be more objective and to collaborate with the other stakeholders when "success" is framed in terms of finding the gaps and flaws in our reasoning and intuition -- when success is framed in terms of finding big gotchas that would surely derail the system if not dealt with. So we embrace "failing" in the small and on the cheap -- well, the biggest cost is to our egos, which, even when our thinking is sunk just in sketches, gets pretty wrapped up in the emerging mental model of the system, so it is important to have mechanisms that make it "safe" and fun to find these gotchas and to prod perspective out of the perceptual ruts our mental models carve. We actively go after those "oh rats" moments that are leverage points for new insight and improvements to the design -- potentially even changes in course. But because all this is happening quickly, maintaining a discipline of fast cycles and focusing on significant opportunities and make-or-break uncertainties, challenges and risks, each point of quick and cheap "small fail" is a big fail saved -- and that is the sense in which the framing is positive. Yes, these are all points of learning and that's nice. But we're investing in not failing big. And that's important. Because failure in the market is failure indeed, and we don't want to do that!
So the point is not that we set out to fail! Duh! The point is that we recognize that there are many ways that our perception and intuition and reasoning will fail us, so we have spurts of acting like we know what we're doing and getting on with it, and then we pause and assume the stance that there surely were some things we overlooked or got wrong, and we seek those out. Which is very cool because our brains love eureka chemicals and while we're problem finding/solving we're making new connections and solving puzzles and finding integrative solutions and all that good "ah ha" stuff. And then we switch hats and treat our brains to "oh rats" induced moments of insight.
All the while applying the discipline of Bucky Fuller's question "What at this extraordinary moment is the most important thing to be thinking about?" Because Escher's Eye is ever looking back at us, and we need to get the system built. So we move quickly from iteratively and incrementally exploring just enough in models (and prototypes) to scoping and building the system, applying the same "extraordinary moment" discipline to focus on not squandering our moments and keeping "the main thing the main thing" -- putting value in the hands/experience of users.
Image source: The quote apparently comes from Growing the Distance: Timeless Principles for Personal, Career, and Family Success by Jim Clemmer, but it is quoted various on the i-way in posts and essays on attributes of leaders.
'There are three variables in the innovation equation: Innovation = ƒ(Strategy + Creativity + Execution)
The need to experiment and fail inexpensively in Execution is where most of the focus is these days. Ironically, the relatively low risk and low cost of experimenting with seemingly dead ideas during Creativity is still one of the keys to lowering the high risk, high cost and high rate of failure in Execution. How many times does someone in your organization say, when a competitor launches a big success, "We thought of that but it died!"'
-- The Positive Power of Failure, Mark Sebell and Jay Terwilliger, March 17, 2011
3/14/11 That Invisible Thread
"What do an airplane, a digital music player, a traffic system, and an e-commerce platform have in common? It is software -- the invisible thread of innovation woven through systems, products and services. ... -- to form a "systems of systems" enabling an intelligent fabric of new capabilities." -- IBM
3/14/11 Stakeholder Profiles
I really like Dan Prichett's user story example. In characterizing a user (telling their story), we suggest looking at activities and points of frustration (mentioned in Dan's example, and also by Douglas Merrill in his ☼Innovation at Google talk), as well as how users would like things to be. This is not the same thing as asking them what they want (specifically from the system), but what they care about.
3/15/11 Steve Jobs -- A Case of Nerves
Steve Jobs from a different point of view (and time): Steve Jobs Early TV Appearance
I see that Grady Booch has a keynote coming up titled "Everything You Know is Wrong." That is such a wonderfully provocative stance! I tend to have the attitude that "everything I know might be wrong," so my internal critics are always on the lookout for "I told you so" moments. But this is different. This is saying "everything I know is wrong!" But, for the moment I'll punt on that, and focus on Everything You Know is Wrong. ;-)
So, if we take the position that Weird Al has a point, then what? Weird Al? You know:
Everything you know is wrong
-- Weird Al Yankovic, Everything you know is wrong
We can catalog the ways that things are changing fast and dramatically for society and business:
"In many cases the social discontinuity enabled by connectivity is touching key leverage points that can completely change the system. ... New business models that bring together resources in new ways are being enabled by increasing connectivity, resulting in more rapid challenges to existing businesses."
-- 4 reasons why an increased pace of change means greater unpredictability, Ross Dawson, March 14, 2011
Reshaping the forces of competition:
Reshaping the organizational landscape:
Reshaping (our conception of) what we produce:
Reconceiving our rights:
We can catalog myths that tend to prop up our world view:
Categories that probably contain things we're wrong about:
Ok, please add to my (super-quick) "top-of-mind dump" on this. It's fun! And remember -- "ideas are like water in an old piping system; you have to run the tap for a while to let out the old, stale water and get to the fresh water." (paraphrasing Tim Hurson, Think Better) If I keep on at this, I might get to the important stuff of "everything you know is wrong."
What? You think listing my journal was just a red herring to check if you were paying attention? Hrrumpf! ;-)
3/16/11: Funny how once you notice something, you see it other places. So, is "everything you know is wrong" a meme I just hadn't noticed, or becoming one? This from today:
3/17/11: This is a great resource for thinking about how (and how fast) the world has changed/is changing:
"As the economy rebounds, tech companies are battling over the engineers, designers, computer scientists, and executives who can propel market share growth within their respective industries." -- ACM Newsgram, 3/15/11
"Several factors are driving the talent
grab. The rapid growth of social media, mobile technology, and e-commerce has
fueled a run on employees with expertise in those fields. The recent increase in
the number of startups is also fueling hiring. And established tech companies
such as Oracle (ORCL), Hewlett-Packard (HPQ), and Cisco are diversifying into
one another's businesses—and stealing talent to speed the transition." -- John
Helyar, Techdom's Talent Poaching Epidemic, Bloomberg BusinessWeek, March 3, 2011
Situated comments! How neat!
"As its name implies, Highlighter allows users to select text. However, Highlighter is so much more than those flourescent pens of yore: users simply select a word, phrase or paragraph, which initiates a prompt to either save, comment or share (via Facebook or Twitter) the selected text. .
.. Highlighter is developing technology that will allow people to take notes and archive information on eReaders, and expects to roll out an app for for Android and iOS devices in the next six months. "
-- TechStars grad Highlighter nabs $300K for blog comment plug-in, TechFlash, March 15, 2011
Why something like Highlighter is important to me:
The Dutch humanist Desiderius Erasmusin his 1512 textbook De Copia, stressed the connection between memory and reading. He urged students to annotate their books, using “an appropriate little sign” to mark “occurrences of striking words, archaic or novel diction, brilliant flashes of style, adages, examples, and pithy remarks worth memorizing.” He also suggested that every student and teacher keep a notebook, organized by subject, “so that whenever he lights on anything worth noting down, he may write it in the appropriate section.”
-- Killing Mnemosyne, Nick Carr, March 07, 2011
“Combinatory play seems to be the essential feature in productive thought.” -- Albert Einstein
Neat article on software metaphors (via Daniel Stroe):
The stuff of dreams...
"There was a dream and there was a budget. A good design/build firm works to reconcile the two in the most eloquent way possible. Our in-house designers sought the advice of our carpenters in terms of the structural details. Our carpenters trusted our designers to conjure something challenging. At the end of the day it took about two weeks to design and about four weeks to construct." -- alice, My Modern Met, March 8, 2011
A different kind of seeing inside...
And seeing over time...
But only in code we trust...
3/17/11 More than the Sum
"In both cases, it’s about building products so feature-rich and reliable that once people experience them, it’s difficult to go back. It’s about adding to and packaging those commodities in such a way that they’re greater than the sum of their parts." -- Derrick Harris, How Amazon Is Following Apple’s Lead to Rule Cloud Computing, March 16, 2011
As for the iPad... I want one!
Decision making in the age of information deluge:
Related to compute-extended memory:
'Because every person was free to chart his own course of reading, to define his own syllabus, individual memory became less of a socially determined construct and more the foundation of a distinctive perspective and personality. Inspired by the book, people began to see themselves as the authors of their own memories. Shakespeare has Hamlet call his memory “the book and volume of my brain.”
... The fear in this case turned out to be misplaced. Books provide a supplement to memory, but they also, as Eco puts it, “challenge and improve memory; they do not narcotize it.”
... Memory, for Seneca as for Erasmus, was as much a crucible as a container. It was more than the sum of things remembered. It was something newly made, the essence of a unique self.'
-- Killing Mnemosyne, Nick Carr, March 07, 2011
Seneca's advice to imitate bees (mentioned in Killing Mnemosyne) is a useful way to think about, and motivate more work on, my Journal Map. :-) [And to push all the entries into a bliki format a la Fowler, etc.]
3/17/11 Technical Debt Illustrated
3/18/11: On a different note, here is an awful story about technical debt, corrupt organizational politics and cowardice, moral hazard, and heroic acts:
3/17/11 Roadmaps and Scenario Planning
"Over the last dozen years that I have been running scenario planning projects I have observed that corporate interest in scenario planning is cyclical. The time horizons that executives think in tend to be driven by the health of their business, the recency of prominent unanticipated events such as the global financial crisis or Middle East upheaval, and visibility of challenges to their business model.
In my experience interest in scenario planning is picking up strongly, reflecting a variety of recent surprises of various kinds, as well as a general feeling of prosperity that permits budgets for the like of scenario projects.
I believe it is also linked to an increased sense that the pace of change is increasing. This is hardly a new sentiment..."
-- 4 reasons why an increased pace of change means greater unpredictability, Ross Dawson, March 14, 2011
Timeline and Trend Visualizations:
"In uncertain times, don't try to predict the future. Systematically explore possible futures." -- Ross Dawson
Looks pretty ("isn't that marketecture Ruth?"), but how does this relate to architects? That's your homework.
3/17/11 The Right Question?
'It’s interesting that when you deconstruct stories of innovation, you find that many of them start with a question--often one that could be considered provocative, naïve, or maybe even a little crazy. ...
It is apt to launch the questioner on a journey of inquiry that may involve in-depth observation, combinatory and lateral thinking, experimentation, and prototyping (after all a prototype, to quote IDEO’s Diego Rodriguez, is itself “a question, embodied”).'
3/19/11 Keeping Track
3/19/11 Abductive Logic à Blackberry
'Long ago, Peirce coined a term for the thinking that Lazaridis used to create the BlackBerry: abductive logic. He referred to it as "inference to the best explanation" and "a logical leap of the mind." Lazaridis couldn't prove that executives would become so addicted to his invention that it would acquire the nickname CrackBerry. But as he watched executives behave in their day-to-day work, he inferred that there was a good chance that they would highly value immediate access to their email regardless of whether they were at their desk or on the road. There was nothing to measure. What counted were inferences; inferences made on lots of qualitative insights and "a logical leap of the mind.“'
-- Roger Martin, Management by Imagination, January 19, 2010
3/19/11 Architect the Playground
"So where does this leave design? It's just as critical as before, but the role of the designer has shifted. The best designs will set the stage but stop short of fully defining the experience. Instead, designers will create open frameworks (with some restrictions) for legions of smart, young things to build the experiences that will ultimately set the best products apart. In that way, designers will continue to become the architects of a vast playground of services that connect people to great ideas, great experiences, and one another."
-- Adam Silver, Why Apple Succeeds: Users, Not Designers, Have the Best Ideas, Mar 18 2011
3/19/11 Innovation as Match-Making
'According to Christian Terwiesch, co-author of “Innovation Tournaments”, innovation is defined as “… a new match between a need and a solution so that value is created.” The novelty can be in the solution, in the need or in the match.'
3/19/11 More Earthquake and Tsunami Devastation...
3/20/11 What's The Itch?
3/29/11 The Art of Change: To Question
"Those who work with Jeff Bezos, for example, find his ability to ask “why not?” or “what if?” as much as “why?” to be one of his most advantageous qualities. That’s why, borrowing a phrase from Ryan Jacoby, an associate partner atIDEO: questions are the new answers."
-- What Bill Gates Could Learn from Chris Rock, Peter Sims Mar 27, 2011
"Preschool kids ask their parents an average of 100 questions a day. By middle school, they’ve basically stopped asking questions."
"... coming up with the right question, the one that casts a familiar challenge in a new light, is an art and science in itself. It demands that the questioner be able to look at an existing reality from multiple viewpoints, including, perhaps most importantly, that of the “naïve outsider.”'
-- Big Innovations Question the Status Quo. How Do You Ask the Right Questions?, Warren Berger, FastCompany's FastCoDesign, March 2011
I used to be so astonished when (several years ago) Ryan and Sara would play these elaborate "story games" in which the absolutely surreal, impractical, wacky imaginative was incorporated fluidly and magically along with elements of mundane, pragmatic reality. The absurd was as possible and likely as breakfast! But think about it -- how real that experience must be for children; our reality is magical! Several years ago I bought an inexpensive digital camera for Sara that had an awesome macro function. I'd never ventured to the expense of a macro lens for my Canon SLR, so while I'd admired macro shots I hadn't personally encountered my world that way. With Sara's camera, she and I joyously explored our yard. Suddenly I was seeing the world as a child again, full of inexpressible magic and wonder -- our world, the world we had experienced with our unexpanded, unassisted 5 senses, became, before our eyes, as amazing and magnificently magnified in possibility as it is to a young child.
Now, Ryan doesn't consider himself a "good writer," generally deferring to Sara when they make movies and such. But the story he has been writing for his creative writing homework these last several weeks has been a pinnacle of minimalist absurdity that is funny and delightful and utterly insightful. It is as informed with acute perceptions about how things work (in the physical and social world) as it is not a bit bound by our conformed "reality." It earned him 105/100, a grade that is as absurdly full of wonder and surprising juxtapositions as Ryan's writing. It was, I think, as much a test of the caliber of his teacher as it was an expression of the undamped imaginative genius of a child. The ability to suspend the mediation of our rational mind is a gift -- one that too many of us lose.
In The Wheel, the child asks "why don't storks nest in Shora?" Adults too often dismiss with a put-down in the form of a question: "so what?" It is a tactic that discourages, that controls outcomes by avoiding the vulnerability of uncertainty by putting the champion of a tentative possibility on the defensive.
We don't just stop wondering. We start objecting. We value being objective, rational, evaluative, businesslike.
We have a paradox because we want questions -- we want the best kind of inquisitiveness or curiosity. The kind that isn't shuttered by "apparent" reality. And we want enough "black hat" thinking to pry away the crud of assumptions, the crust of "the way things are" and to (fore)see failures and risks. But we don't want to deflate the team. There is a slate of questions, some even innocently intended, that can feel like a slap. That deflate and undermine.
This makes the role of the leader in innovation crucial. The leader needs to keep the "big idea" (the compelling composite of ideas that transforms possibility) alive, nurturing it and in some, but only some, ways protecting it, even while adapting and reconnecting and re-engaging and morphing it. We find the thing we can do, to start to build and test the idea. We engage. We face set-backs. The draw is our belief in the need that we are addressing. Our understanding, our perspective, our framing of the need takes shape. But the need is what compels and orients. It impassions and enthuses. And the need is often glimpsed by questioning the status quo, by asking "why don't storks...?" It is Kennedy's "why not?" line of inquiry -- one that takes the position that the present is a created complex artifact of history, intent and accident; one that is under change no matter what we try to hold onto and reinforce. It is an innocent, eyes wide with wonder and expectation of grace and "magic" kind of stance that asks "why not?" with exuberance and willful buoyancy. It radiates from a stance of awe-struck seeking, of child-like optimism, of shaping the great thing to be done, to be made real in the world. Pragmatically -- where that counts. Yet optimistic even to the point of seeming unrealistic obstinacy. We form an opinion, a set of ideas, a dream, of what must be done.
And then. The wash of encounters with defenders of what is. Compromise on what matters is erosive. Rejection and belittling is designed to destabilize and deflate. The leader has to find a way to nurture that delicate "flower of innovation" and let it flourish, knowing that cloistering it from criticism (or praise) will not prepare it for the buffeting of the "real world" -- nor even will such a buffering be what it needs. For it needs to learn, to adapt to that "real world" even while it reshapes its world, reforms its context in that bio-mutual synergistic way we expect with organic systems.
Innovation is hard because it requires penetrating discernment at many points, at many levels. Discernment. Seeing through the extraneous, intuiting what isn't germane, finding what is critical -- there is so much that just obfuscates the real need, and the compelling, exciting, wondrously doable approach to addressing that need. And it takes shielding and "sticking to it" sometimes, and letting go and retrenching and reforming and reshaping often the very formative idea that began the quest. Part inspired. Part serendipitous. Part determined, obstinate, courageous. But more! Importantly more -- optimistic, passionate, delighted, and simply audacious. Simply, naively, sweeping aside the leveling of expectation and precedent and with unself-conscious, unforced, innocent audacity reaching for the big thing that just must be done.
This tenacity doesn't have to be arrogant and assertive or defiant. Arrogance is too close to contempt. Contempt divides. It attempts to create certainty by dominating and shaming and belittling others, putting them in a weak and defensive position.
Can we develop a more child-like ability to co-operatively imagine past what is, and find the interesting world-order reshaping questions? It helps to foster in ourselves a habit of awe-struck seeking --- following our Bliss, full of amazement at what is, and at what is possible! Gratitude and wonder just take moments of standing still and feeling, seeing, hearing, reflecting. Gratitude is a stance full of amazement. And amazement is a positive place from which to see the world beyond the constraint and inertial tendrils of the "politics of proper place" of now.
And yet. Conformity is a most seductive force. It must be, for though we pay lip-service to non-conformists, to the child's ability to question, to imagine, to be joyful, we chisel and hammer our world into conformance. We fit experience to expectation, downsizing both.
Paradox, then, is the field in which resilience in innovation is grown.
"The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function." -- F. Scott Fitzgerald
The genius of a child is the ability to combine make-believe with a keen sense of the "real" world. We admire this genius in Lewis Carroll (actually Charles Lutwidge Dodgson writing under a pseudonym -- isn't that revealing?) or Rudyard Kipling. And Jeff Bezos. First, to ignore the distortion of our built and perceived realities. Then to put books on a device to the pooh-poohing even of the man who put music on a similar device, only smaller. To be followed, of course, by that man, but in full color. Because we dream and draw and see the world in color, so why not our books?
And that, of course, is another children's story! Which? If You Give A Mouse A Cookie, of course! Right there, in a classic and adorable children's book, is a key to innovation that is overlooked time after time. What? If you give a mouse a cookie, he is going to ask for a glass of milk. And if you give him a glass of milk, he will ask for a mirror (to see if he has a milk mustache, naturally). And if you give him a mirror, he will ask for a pair of scissors to give himself a trim (what one sees when one looks in the mirror)... and so it goes. What if? What then? ... And what then? Or what else?
3/30/11 Zoom. A Metaphor
Rosabeth Moss-Kanter's Managing Yourself: Zoom in, Zoom out HBR article and interview ☼Zooming: How effective leaders manage their focus are interesting and quite relevant to/a nice follow on to yesterday's post (for example, I mentioned discernment, she mentions seeing what's important). It also hits on themes in our Art of Change: To Lead is to See, to Frame, to Draw paper, and calls this post to mind, and in particular these words:
Anyway, out rambling and taking pictures, I remembered someone complaining that he didn't like to see the world through a viewfinder. Well, it's not viewfinders necessarily any more, but it is still paying attention to the frame-view rather than the wide pan view. I find it is much like our process--wide scans, and dropping into detail when the detail begs attention. If I wasn't looking to take in the scene but all-the-while being alert to photo frame views, I would miss that detail. And that is what I love about Brian's visual journal and his talent as a photographer. Beautiful landscapes and exquisite detail in a flower, an insect, a mushroom.
... Focus helps us get things done. Scanning the context from time to time, lets us pick where to focus and alerts us when that focus needs to shift. We need to do both. But our tendency is to tunnel, to get mired in inattentional blindness. Or to scan; to stay too high-level. Our process needs that forth and back.
I really need to get that paper wrapped up, but I've been so busy meeting client commitments that when I have moments to write I just want to explore, be playful ...not write something formal.
3/30/11 Gives One Pause...
3/30/11 The Moral
"In this case it was a software update that caused the problem. That is to be expected. More disasters have probably been caused by software updates than any other cause. The reason: bugs that effect control are more powerful than bugs that effect data."
3/30/11 Thank You!
Reminding me that good people are doing kindness in the world:
3/31/11 And Here Come the Girls
Tonight I told Sara what a job in IT is. She said:
"You mean, the job is being a geek? That's awesome! I'd love to get paid for being a geek!"
I also write at:
- Bredemeyer Resources for Architects
Contact me at:
- JD Meier
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
- Werner Vogels (Amazon)
- Jonathan Schwartz (Sun)
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