Thinking aboutA Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

January 2011


Well, there generally seems to be a sense that we're ☼well rid of 2010♫. I hope that 2011 is enriching and rewarding in every way. Make your systems great so you do your part to spread technology optimism! We have another round of technology-driven economic resurgence due. Overdue!,

1/1/11 The Useless

With almost 5 years of journaling here, it is time to properly frame the value of my journal. ;-)

The Useless

Hui Tzu said to Chuang Tzu:
“All your teaching is centered on what has no use.”

Chuang Tzu replied:
“If you have no appreciation for what has no use
You cannot begin to talk about what can be used.

The earth for example, is broad and vast
But of all this expanse a man uses only a few inches
Upon which he happens to be standing.

Now suppose you suddenly take away
all that he is not actually using
So that, all around his feet a gulf
Yawns, and he stands in the Void
with nowhere solid except right under each foot:
How long will he be able to use what he is using?

Hui Tzu said: “It would cease to serve any purpose.”

Chuang Tzu concluded:
“This shows
The absolute necessity
Of what has 'no use.'”

-- The Way of Chuang Tzu, translation by Thomas Merton, 1965

A software architect is generally a software engineer or computer scientist by training and by experience, but an architect is more than an engineer. The architect creates that crucible for engineers to do their work thinking they did it all, each themselves, and yet it coheres within a system that has integrity.

Hence the architect, perhaps, has to step beyond the circles of past comfort. My journal has the distinction of being truly useless and well beyond the comfort zone of all but the most curious and playful of awe-struck seekers. Reading here is like, well, a tolerance for ambiguity workout. In short, if this cap fits... don't read another word. Imagination and goodwill being required to get the absolute necessity of what has no use.

Ah but, given that you're fresh with resolve to work that organ that consumes "respectable" calories, why, December had its share of useless posts. November too. And if you really start to feel the necessity of what has no use, well, I've been working on a Journal Map, so you can navigate your way around this tumultuous landscape of words welled in the wonder of exploring our field.

Still Here? Wow! I'm impressed. Perhaps you'll make it into the small and select set:

Now, to be clear, this journal is first and foremost for me. I am my own harshest critic, and I don't wish to be challenged from that rank. And then this journal is for a small and very select set of architects who are extraordinarily smart, who have an intelligent sense of humor that catches the many layers of satire, irony and wit that permeate my writing, and who are so comfortable with their own rare and outstanding qualities that they can stomach my occasional indulgence in self-congratulation. Ok, quickie quiz: just what part of this is satire and irony and what part wit?  -- 2/21/08

Meta-reflection: My journal has a tendency to self-destruct. This post being a case in point.

PS. Don't follow the links. Do not follow the links. Especially, do NOT follow the links to posts on my site. Nothing to see. Really. No, really.

1/2/11 Looking Forward and Back

This New Year's greeting from Daniel Stroe was the most thought provoking of all I received (not to diminish any, for I deeply value each expression of connection and goodwill):

O Janus! you that looks to the past and to the future,
Aren't you fathering with your gaze our mind split?

We are already in the 1st day of Janus (January).

Indeed, sic tansit gloria mundi ...

On this note, the Guardian has named a series of photography -
Ruins of the American dreams.

We'll have dreams that will flare realities and we'll turn our back and forget them, and they'll forget about us and we'll pass the genesis of the dreaming to our offspring.

-- Daniel Stroe, personal email, 1/1/11

Isn't "dreams that will flare realities" exquisite? And isn't the indifferent wash of time, the sediment of dreams reached for and sometimes attained, yet always ultimately broken, so depressing?  Daniel ends with the question:

Why should we dream about dreaming?

Because our dreams are our affirmation of our individuality and reality. "Cogito ergo sum."  And I dream, therefore I become. Dreams are what make us, in Bucky Fuller's words, "a verb" -- an intentional and vibrant verb. Our dreams are essential to making a distinctive mark on this planet, however brief. They give us that welling of rebellion, the passion to resist the damping damning dust of indifference -- to our own self!

January. We stand ever at the portal to the future, but the turn of the year reminds us to take stock just enough of the past to inform and energize our future. To reassert our dreams, the invention of our self, and our resolution to make a difference, refocusing on the important to flare and forge the realities that have their genesis in our dreams. And to feel an increasing sense of urgency with the quickening rush of time♫ (for perspective, this is PF in 1972 doing time/eclipse).

Thank you for reminding me, Daniel.

You lead well.

1/2/11 Damping Damning Dust -- We (Must) Resist!

Last January, I wrote this:

A compelling dream and real urgency. A fine-tuned aesthetic sensibility ensuring integrity, while the urgency cuts away the fluff. Not the fun! Just the extraneous, unnecessary turf tzaring with all its circling and dominance antics. The vision aligning everyone, the urgency creating focus on the critical. The result? Enough to set me back on my heels to howl at the moon for dreams lost in mediocre meandering, death-pale spirits that haunt our schools and work-worlds rasping and sanding down aspirations into conformity with an un-ambitious norm. A man-child showing us what can be done with a life, while we shuffle dust, filling days.      

All that reaching, striving, yearning to leave an imprint on this world that is coldly indifferent to our desire to stay in it, summed up in If I Can Dream -- a kid singing of the taste of life even as death rose in his mouth and throat.

If I Can Dream indeed!

So dream! Then--just do it!

I wrote that post in celebration of Killian Mansfield. It has echoes of another post, written in memoriam and gratitude.

People have a tremendous impact on us. We think we are so distinctly ourselves, and yet there is such a parade of minds whose thinking (and testing, proving, building in the world) gets woven into us in ways we don't even recognize, could often not trace.

Yesterday Dana printed off the December "issue" of my journal (so he can read it away from the anchoring of a screen) and goodness, it was 35 pages long! Was. Subsequent to that, I added back in entries so that the archive version was more complete. I also added entries back in to November. I once told someone not to follow my journal because he has to have time in the day to think his own thoughts. (He took me at my word! Hello?!!)

I guess I don't need to tell my husband that, because he only plans to read my journal. No, just kidding. He's my most loyal and kind reader. For example, I told him he can't detach from the screen 'cos all the good stuff's in the links, and get this -- he said "nah-ah." He tells me my eyes are more blue in the most delightful way. (Seriously!) No, no, not blue, but more blue. If you didn't pay attention in December you won't get that, but never you mind. It was good. Great even. But you have great thoughts to think too, and great systems to design and help build. 

At any rate, I really write a lot when I'm avoiding writing. I mean, when I'm incubating the next pieces of work that will help our field know itself, seeing what needs to be done in the creation of sustainable systems. Sustainable in every sense. Yes, the refrain if you please: sustainable in every sense of the word from technically to economically and environmentally to morally and personally.  

What? Look, I framed the audience for this journal and so clearly if you're still here you are one so comfortable with [your] own rare and outstanding qualities that [you] can stomach my [exceedingly] occasional indulgence in self-congratulation are you not? No? Look, that entry was specifically designed to fend off all but those with the most acute appreciation for my ... brand of useless procrastination.  

Phew. Ok, word to the wise -- we call this an invisibility cloak. Also known as a veil of words. So donned, we can proceed to the good stuff in the remainder of January's post. We hope!!

I know, I should put more of the time I sink into this journal that so few people read and none recommend into getting the Visual Architecting book finished already. I should. But I also feel that I'm working this new medium of expression to an extent few others do groan in agreement, thinking extent=expanse, vast expanse, while I think it is a form that can be more vibrant, more pulsing with life and multi-dimensionality than any book. The very surprising twists and turns, the soaring heights, the plummeting to plumb depths made more comfortable with an ever present twist of humor. And gosh gee, it's free! Well, there's the small matter of the cost of time, yours and mine. But you know, how does one assess the value of what is useless? No, we're not going to put my journal on eBay to see. Garr! 

1/3/10: So, you see, it is not that I do not pay attention to and serve my audience, much as one might conclude that I pay no due respect to the value of the time of those who drop by here, nor the desire for the actionable grist with not so very much of this chaff. This is an exploration, not a distillation. This is a wild landscape, not a neatly tended formal garden.

I've read various software architecture document pundits advise "document in one place only." A decision model helps with having a "proper place" to put decisions and the models and descriptions that explicate, rationalize, contextualize, defend, advocate, and guide the implementation of, these decisions. But, of course, it you create a reference document and a more consumable-by-all-stakeholders overview document and/or presentation (set), you've put things in more than one place. More to maintain. But we have to start to see the architecture being worth the kind of attention it takes to both keep an accurate reference along with more digestible viewports and keep these up-to-date with the evolving architectural intent and realization. We have to serve the advancement of the architecture by serving our own (core team's) understanding of what needs to be done. And we have to serve those who the architecture impacts in various ways.
A software architecture decision model provides an organizing structure for decisions and the models and descriptions that explicate, rationalize, contextualize, defend, advocate, and guide the implementation of these decisions.

So clearly we need to think about audience with an orientation that respects their time and the outcomes they seek. My audience here is amazing. Yes, smart with a great sense of humor, and humble (as only those most comfortable with their rare qualities are), etc. But what I'm getting at is that this audience is truly diverse with every continent multiply represented by those who regularly stop by this journal. Some are at universities but for the most part "you" are architects from across the spectrum of industries and public agencies. There's also a spread in experience levels and job scopes. Well, of course I don't know who you are, but I get enough of a window to know there is this diversity. What, in my assessment, is the point of commonality, beyond a passion for architecture? Curiosity, an orientation to playful investigation -- that awe-struck seeking. That and a gentleness, a desire for things to be better in this world. And optimism. Glorious, irrepressible optimism! But, curiously... this curiosity extends very little to following the links within my journal. Apparently the view of the current month is more than enough (to quench -- or drown -- curiosity and damp optimism)! Or perhaps (optimism resurgent) my value is more as a comic scout than anything else. ;-) But -- I'm a great comic scout, aren't I. ;-)  Nah. It's really that those cartoonists are out there writing just the perfect vignette to playfully punch up a point I'm making. It's so markedly nice of them!

I write with candor, yes. But I also candidly ward off those with a Procrustean approach to human spirits (those who diminish people by imposing a small mental frame upon them), with plenty of "warning: Q<= writes here" signs. (Hmm, yes, isn't my New Year's greeting image utterly delightful? Sara is just entering, and is totally taken with, the manga/anime world and is inspired to learn Japanese as a result. If that didn't quite do it, there's the diversity stretch sketch reminding us of undiscussables like how women are really seen in technology.)

And for those who are just too busy, well of course there's the "warning, warning, warning" of "words, words, words."  Indeed, I drew the image (above right) for the top of a journal page back in 2008, but then I decided the words themselves were amulet enough. ;-)

I have playfully said that it appeals to my sensibilities and sense of humor that this journal both veils and unveils me, and googling the phrase "veil of words" lest I be cliched (what horror!)... came upon two references -- right above my site on the first page of Google results. They both relate to, and are wonderful references (The Problem of Perception and The Veil of Signs) for perception! Which is the theme, to be playfully illumed with magic, for that day of the Leadership workshop I told you about last month. ;-)

Perception. A theme for an architectural leadership workshop? Well, it's secondary (in the weft), but it threads through everything we do, doesn't it? What impedes perception? How do we influence and persuade? How do we communicate more effectively? What do we elide, so that we better elucidate? These are all pivotal in architecting. And front-and-center matters of perception.

A veil. A post titled a "note to persist" that has within it the most pithy, most useful yet concise, guiding statement characterizing an architecture decision model. ;-)

I write to educate myself. It is very much like architecture -- often we have to expand, to add detail, to find the bare frame, the essence of the thing. To explore in the shadows, not just under the light to find the key.

And it is value great to me if it stimulates questing connection making, insight generating for you too.

And I write to celebrate the glory in the everyman. Yes, those whose work is admired and which puts them in the spotlight of the public mind. But also those who work quietly behind the scenes to make things better in the world they impact, and in so doing, make things better in our world. 

1/3/11 Building to Something

We become the ideal we hold out to ourselves:

First say to yourself what you would be; and then do what you have to do." -- Epictetus (AD 55 -  c.135)  

"If you wish to be a writer, write." -- Epictetus (AD 55 -  c.135)

“Men acquire a particular quality by constantly acting a particular way... you become just by performing just actions, temperate by performing temperate actions, brave by performing brave actions.”  -- Aristotle (384 BC - 322 BC).

Again, we become the ideal we hold out to ourselves -- not absolutely and without any compromise, but more, the clearer we make that ideal and work towards it. Otherwise we just fall into others' (too often Procrustean) views of us. (Procrustean? Think, for example, of the over-ambitious mother - or father - who projects her ambitions onto her children.)

We may not (yet) have a sense of where-to, but following our bliss is leading us. Sometimes we're incubating what we will become, without a clear sense of what we might make of that, falling only to the draw of the dimly sensed shape of our passion and the guiding/forcing hand of Serendipity and the chance placement of opportunity and hurdle, the choices we make at the various cross-roads and dead-ends our lives take as we accommodate our aspirations and those of our families and colleagues.

I read this characterization of Saint Thérèse today: "She was young, modest, private and obscure, and did nothing remarkable, except struggle to be good." I protest! That she did, but she also wrote vividly about her struggle to be good; shared that struggle and its lessons. We build in ourselves the capability to build in the world and our finely tuned sensibilities give shape and beauty to what we build. I watch our kids I am staggered at the work they do! Sara is constantly drawing, writing, dancing, composing, creating and is mind-blowing fast at math too. Our son is constantly studying, analyzing, building a rich (and often hands-on) sense of the world in various dimensions from music to literature to engineering and bioscience. He is building a knowledge of The Lord of the Rings to rival Tolkien's, I think! These are aspiring spirits and the work -- in their work and in their play -- never stops!

Steve Jobs' "connected dots" (Stanford commencement address) is a great lesson. Afterwards we may look back and see how the curious path of our lives led to a "ding" but from here we may see neither the form the ding will take, nor the relevance of what we are doing now.

The struggle to be good is a struggle indeed. And being kind to others has to begin with being kind to ourselves. If we don't have a clear sense of a ding we wish to set ringing across the expanse of this globe and of time, but only that we hope some day to do that, then we need to let our bliss lead us there. To do what we love, and to love what we do are self-reinforcing, mutually building. We may end up being surprised at where our various proclivities, riding upon the currents of destiny, bore us. But for now, we have to trust that if we don't see "a big thing" worth doing, then the seeming little things we do to make a difference (in our work, our families, our local and virtual communities) are just as worth doing, and worth doing with passion and zeal. Gentle action, touching ripples of change, after all, is what changes the world in powerful ways. Following, throwing ourselves into the dream another inspires, is as important as leading, for big things aren't done without good following. And good following is good leading, in the next circle of influence. You know, leadership is fractal. 

Um. I just thought I'd say that. Now I have to write about Leading. ;-) And Innovation. And ... well, that I can't say.

This quote comes from a footnote to an architect's New Year greeting:

"The future belongs to those who believe in the beauty of their dreams." ~ Eleanor Roosevelt

Those may be dreams we forge alone, or a shared dream forged in the crucible of a team, or just as validly, we may fall into the embrace of another's dream. Regardless, these dreams -- what we see but barely yet begin to build anyway, chipping away at uncertainty until the dream, the difference we set out to make, is realized -- create a better world. Yes, dumb luck, bad luck, good luck -- and any other form you think Serendipity takes (perhaps the guiding hand of angels or the ripples beyond ripples in the wake of all from geniuses to hapless fools) -- plays its hand. But we sentient beings aren't happy simply to cast our lot to the indifferent winds of fate. We wrestle to make things and states of being different in our world.

Since you are so patently bad at following my suggestion (hrrmpf), I'll quote myself rather than giving you the link (oh come, I tease, but only playfully):

We aren't mere windsocks responding to the direction of the wind; we make wind!

Yes, my trademark double entendre. In context:

One other flaw in much of the "we must respond to a changing world" thinking is that it neglects our impact on the world. We aren't mere windsocks responding to the direction of the wind; we make wind! We change the course of history, in small and big ways, with what we create. We change expectations about what is possible. We interact with destiny, don't just simply bow to it. Though, to be sure, we ignore these forces at our peril. But ignoring our role in shaping expectation, shaping the world into which our systems will fit, is just as one-sided as blindly expecting users to force-fit our product offering to their needs. The world of pragmatists is the world of balance, the world of tradeoffs. This is just as true for the process we adapt to fit our needs as it is to the products we generate thereby.


Alright, alright. Not only is this the turn of the year, but it is time for those chocolate frogs!

I diss myself for being "self-helpy" when I write posts like this. But what is self-help anyway? Applied psychology simplified for mass appeal? I'd never fall into that category!  ;-)

4/9/11: You're writing you own story, the story in which you are the hero.


1/3/11 Enterprise Architecture and Innovation

"A challenge for IT is how to provide structure and process for business-focused technology R&D. Enterprise architecture (EA) groups have the best set of skills within IT to do this by managing the firm's innovation pipeline and developing the firm's innovation network. But EA groups must recognize the role they should play in this to enable the pipeline to be as productive as possible."

--  Enterprise Architecture's Role In IT-Enabled Business Innovation, Alex Cullen

"Whether it was because they were technical by nature or if it was just more fun to play in the technical realms, Enterprise Architecture in most organizations has become the bastion of standards and policies, but one that spends very little time actually talking about the business strategy."

-- Charles Araujo, "Is Your Enterprise Architecture Stifling Innovation?", Castlepointe/, Sep 2, 2010

"New technology/innovation introductions Enterprise Architecture allows a proactive approach in assessing the adoption of new technology and innovation. Technology and innovation is often assessed reactively, rather than against future business capability requirements. Projects maybe delayed while time-consuming technology evaluation takes place; there is also the risk of a project-focused evaluation rather than enterprise focused one."

-- Federated Enterprise Architecture, e-government, New Zealand

"The aim of this conference is to examine how information technology enables and generates innovation and thus provides value to enterprises. The goal of this conference is to discuss and share best practices, experiences, models, methods and tools for innovation and enterprise renewal."

-- International Conference on IT Enabled Innovation in the Enterprise -- ICITIE 2011 Call for Papers

"In today's global world-and due to the perfect storm of economic crisis, unprecedented competition and limited access to capital that we've experienced in recent years - people are longing for leaders who can anticipate, rather than react".

-- Michael Kemper quoted by Melvin Greer in Leadership 2025, Essential Qualities for the Future,  11/12/10

Hybrid thinking combines the analytical mastery of architects with the intuitive originality of designers. Hybrid thinking drives change via the co-creative exploration of meaningful human-centred experiences when confronting complex, intractable issues, also known as “wicked problems.”

-- Gartner Says Hybrid Thinking for Enterprise Architecture Can Help Organisations Embrace Transformation, Innovation and Strategy, May 13, 2010


1/3/11 Just for Laughs

Did you see Cringely's "The 10 dumbest tech moves in 2010"? I know it's (almost) a week old -- no-one told me! (So I also hadn't seen, "How the Cringe Stole Christmas"...)

Some of these 30 Funny Graphs are good for a chuckle too.

1/3/11 Bugs We Do and Don't Need

Don't: Skype crash: Software bug and server overloads blamed,

Plight of the bumblebee, 11/17/2010

1/10/11 Civic innovation: Local Coders Help Improve Government Functions There’s a new breed of software developer helping local government. by Tina Trenkner, January 2011.

"... I have often found system dynamics modelling of the cause and effect relationships between objects (causal loop diagrams, stock and flow diagrams), popularised by Peter Senge’s The Fifth Discipline book, to be a useful approach for analysing how a system works. iThink is a nice tool for doing this sort of modelling."

-- Adrian Campbell, Does Enterprise Architecture stifle innovation?, 18 March 2009

1/4/11 Business Intelligence

Business intelligence = operational intelligence + competitive intelligence + strategic intelligence

(to inform and improve how and what we do in the business, in the market, and in the future)

Am I missing anything? (Like, the whole point?)

1/4/11 No Botticelli's Venus

I loved Anthony M's response to Nick Malik's post on EA governance and innovation:

"I agree that you need a steam-release valve when innovation comes along. But I'd like to point out another commonality - in all your examples the actor provided the answer, fully grown, like Botticelli's Venus. The establishment was backed in a corner - they had to be 'wrong' for the idea to be right. Luckily EA teams need not take such a 'wooub' approach when envisioning the future, and creating rules.

They have opportunity to create joint ownership as the vision and rules evolve is a bit better, and agreement as to the governance approach.

"That to secure [This Strategy], [Enterprise Architecture] is instituted among [The Corporate Hierarchy], deriving their just powers from the consent of the governed — That whenever any Form of [Enterprise Architecture] becomes destructive of these endsden cl, it is the Right of [Senior Management] to alter or to abolish it, and to institute new [Enterprise Architecture Team]," - with apologies to T. Jefferson."

-- Anthony M.

I'd like to refer you back to my post on Architecture Principles (note the duration discussion and the scope clause). Nick makes a good point, though it is not inconsistent with the way we talk about principles. It is worth highlighting the importance of the "open door," the willingness of the architect to (re)consider the (innovative) ideas and objections of those impacted by the architecture. The "crying towel" notion only says that if the architect decides that the architecture decision needs to be applied (granting no exception or amendment in this case), then it needs to be applied or the applicant needs to seriously weigh invoking due process (governance). Why? Because the architect needs to be open to better ways to do things, but also is responsible for system outcomes -- for making something strategic better. That's the architect's judgment call. It is important for the organizational culture, with the tone being set by management and other technical leaders, to support the architecture and demonstrate good following, but governance generally allows for an escalation path to arbitrate and provides a higher level of decision authority the option of hearing a case for exception (innovation may, after all, impact strategy). You don't want to be in a situation where the governance process gets snarled up with endless exception requests -- that would be a sure sign your approach is being seen as heavy-handed/heavily constraining... It may be the right vision, but how you get there might need revision.

Leadership isn't just about setting the vision, but how we get there not by mandate and commandeering, but drawing people in, aligning and empowering and drawing on the best in them to accomplish that vision. Yes... To Lead is to See, to Frame, to Draw...

Caveat: A leader may choose to use some mandate supported either by organizational authority (like power over resource allocation) or passion and charismatic emotive force -- being dramatically (and authentically) stern when core values and principles are jeopardized, breaking and rebuilding rapport, etc. But there is a "sliding scale" -- one that is easy to slide down and harder to get back up -- from organic, empowering, collaboration-enabling leadership to command and control-styled dictatorship.

And seasons turn. We see plenty of organizations (from projects all the way to the corporate level) flip-flop between the yin and the yang of network-facilitative and command-and-control dominance styles, for too much of one gets seen as the ill that has to be addressed, and seeking correction, the other extreme is promoted. How many times have you seen this: Network facilitative leadership gets something ambitious going. But the project takes longer than anticipated (Hofstadter's Law) and the management team gets antsy, there's politicking behind the scenes, and either the project is cut, or a more authoritarian manager is brought in to set things to rights, the pressure gets turned up, and the thing gets done. Compromised, but done. 

1/4/11 Are Architects Obsolete?

Well, a day in the hype spotlight generally means there falls a night of hype-backlash. Has architecture fallen into this shade?

I was watching a presentation on agile and a key thesis was that heavy-weight plan-driven processes have roots in Taylor's scientific management, in which processes designed by "process experts" are imposed upon workers. Agile, by contrast, it was argued, holds that teams choose what process to follow.

Perhaps a useful distinction to rather make would be that agile processes are (in their best incarnations) organic and adaptive. They don't prescribe finely compartmentalized and routinized work designs. Those who promulgate the likes of SCRUM and Kanban, TDD and continuous deployment, and VAP, have distilled lessons of experience across many projects to provide some level of "scaffolding" so teams can leverage what has been learned (rather than learning the process lessons from scratch every time, which is as much a waste as developing all of a project's infrastructure and development environment tooling from scratch each time or re-inventing patterns over and over, and over). Some of these processes, like VAP, enable collaboration, communication and integration of work so that more organizationaly and cognitively demanding (more complex, and requiring deeper and more varied specialist expertise to be bought to bear) systems can be built -- created, that is.

Yes, VAP. 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.

In Taylor's day, things were incredibly different than they are now. Route processes that could be optimized and standardized were performed by humans, and yes, they were often more efficient, in this paradigm, following the designed routine set for them. This is not to say that all processes were route, but where they were amenable to rendering work repeatable, finely compartmentalized and routine, the improved efficiencies earned advocates -- along with criticism for the human toll on quality of work-life and reduced bargaining power for now much more "plug-and-play" workers who could be quickly trained to do repetitious small chunks of work. But today, such mechanistic processes are increasingly mechanized and automated. As fast as we can, we have replaced human workers with robots and automation in factories (well, this is still ongoing, but the transformation of manufacturing has been massive), and digitization has been moving into service realms apace. This is the march of lowering costs and improving productivity and increasing our ability to accommodate and advance the complexity inherent in human accomplishments and technology-enabled products and services. We've been creating products and services that have reshaped our work and personal lives in diverse and pervasive ways.

The development of those products and systems, on the other hand, is anything but routine. So the processes we talk about in development are of quite a different nature to those where the work can be routinized. They have more to do with the co-ordination of complex highly cognitive work. If we place value on small, highly empowered, self-organizing teams, and at the same time we want to create complex systems, we have to provide sufficient context so that the system will have integrity and be sustainable.

That "sufficient context" is dependent on system and organizational complexity. I so often see discussions of agile, especially those in the offensive against Design Upfront, proceed with no reference or sensitivity to the role of complexity and uncertainty, challenge and risk. The more complexity, the more minds we need to engage to create the system, the more we need to do upfront and along the way so that we get a synthesis with system outcomes that are better than an aggregation of disparate, poorly integrated parts. Yes, yes, we want to do just enough upfront. And we want to start to seed fan-out as early as possible, involve more people, leading people. (I said minds right there, but then I caught myself because people bring bodies and moods and physical states and abilities that are not only cognitive, etc., etc., to the process so I scolded myself for focusing only on minds. ;-) Discussions of KANBAN, for example, may never mention architecture or architects, and give the impression that we "don't need no architect." But as soon as we seek to build complex systems and scale any of the Agile processes and their derivatives, we start to see Agilists reaching over the divide (they drove, marking out a territory for Agile to claim) to architects and architecture (just enough design upfront and more along the way). 

So, no. I don't believe architects are obsolete. Because design is not obsolete. Quite the contrary. Though we orient ourselves to doing just enough design upfront.

Journal Archives

Journal Map


- January
- February
- March
- April
- May
- Current


- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December


- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December


- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December

More Archives


- The Useless

- Looking Forward and Back

- Damping Damning Dust

- Enterprise Architecture and Innovation

- Just for Laughs

- Bugs We Do and Don't Need

- Visualization Tools

- Business Intelligence

- No Botticellis Venus

- Are Architects Obsolete?

- Software Architecture Workshops

- On Tilting at Windmills

- On Experience as a Teacher

- Sarandipitous Images

- Visualizing Why We Need Architects

- Musing About Muses

- Marvin Minsky

- Visual Architecting

- Chuckles Perhaps

- Quixotic Doesn't Fly

- Not Those Boxes

- The Awesome Habit

- More to the Core

- Mind and Hands Building

- Tread Softly on Dreams

- Decisions and Concerns; (re)Defining Software Architecture

- Them Tricksy Words

- Interactions

- Navel Gazing

- We Build Ourselves to Build Our World

- A Visual Moment

- A Musical Moment

- An Olympian Moment

- In Honor of Martin Luther King


- Technology Driven Resurgence

- Instrument and Visualize

- Art in Engineering

- Visual Complexity

- Design by Analogy

- Self-Organizing Development

- Architectural Form versus Structural Form

- Wordle Fish

- I'll Never be Alone Again

- Imagination Makes the Difference

- A Kludgy System

- Serendipity Indeed

- Adventurers

- Golden Carrots

- Evening Tracks

- To Trace or Not to Trace

- On the Whole

- Failing Into Success

- Context Factors

- Clean Slate




Chief Scientists

- Grady Booch

- Michael Feathers

- Martin Fowler

Enterprise Architects

- John Ayre

-Peter Bakker

- Stuart Boardman

- Todd Biske

- Adrian Campbell

- Louis Dietvorst

- Leo de Sousa

- Johan Den Haan

- Chris Eaton

- Roger Evernden

- Ondrej Galik

- John Gotze

- Tom Graves

- Melvin Greer

- Adrian Grigoriu

- Carl Haggerty

- Dion Hinchcliffe

- Paul Homan

- Brian Hopkins

- James Hooper

- Martin Howitt

- Kristian Hjort-Madsen

- Alan Inglis

- Janne J. Korhonen

- Nick Malik

- Alex Matthews

- Brenda Michelson


- Sethuraj Nair

- Doug Newdick

- Steve Nimmons

- Jim Parnitzke

- Chris Potts

- Randall Satchell

- Praba Siva

- Serge Thorn

- Bas van Gils

- Jaco Vermeulen

- Richard Veryard

- Mike Walker

- Tim Westbrock

Architects and Architecture

- Charlie Alfred

- "Doc" Andersen

- Tad Anderson

- Jason Baragry

- Simon Brown

- Peter Cripps

- Rob Daigneau

- Udi Dahan

- Tony DaSilva

- Matt Deacon

- Peter Eeles

- George Fairbanks

- Kevin Francis

- Sam Gentile

- Simon Guest

- Philip Hartman

- Todd Hoff (highly recommended)

- Gregor Hohpe

- Steve Jones

- Frank Kelly

- Kirk Knoernschild

- Philippe Kruchten

- Sjaak Laan

- Dave Linthicum

- Anna Liu

- Nick Malik

- Chirag Mehta

- JD Meier

- Kris Meukens

- Gabriel Morgan

- Robert Morschel

- Dan Pritchett

- Chris Potts

- Bob Rhubart

- Arnon Rotem-Gal-Oz

- Carlos Serrano-Morales

- Shaji Sethu

- Leo Shuster

- Collin Smith

- Brian Sondergaard

- Michael Stahl

- Daniel Stroe

- Gavin Terrill

- Jack van Hoof

- Steve Vinoski

- Mike Walker

- Rebecca Wirfs-Brock

- Rodney Willis

- Eion Woods

- Brian Zimmer

Architect Professional Organizations




Software Visualization

- Adrian Kuhn

- Jennifer Marsman

Domain-Driven Design

- Dan Hayward

Agile and Lean

- Scott Ambler

- Alistair Cockburn


- hackerchickblog

- Johanna Rothman


Agile and Testing

- Elisabeth Hendrickson

- Elizabeth Keogh

Software Reuse

- Vijay Narayanan

Other Software Thought Leaders

- Jeff Atwood

- Scott Berkun

- CapGeminini's CTOblog

- John Daniels

- Brian Foote

- Joel Spolosky

CTOs and CIOs

- Rebecca Parsons

- Werner Vogels (Amazon)

CEOs (Tech)

- Jonathan Schwartz (Sun)

CEOs (Web 2.0)

- Don MacAskill (SmugMug)

Innovate/Tech Watch

- Barry Briggs

- Tim Brown (IDEO)

- BoingBoing

- Mary-Jo Foley's All About Microsoft

- Gizmodo

- Dion Hinchcliffe

- Oren Hurvitz

- Diego Rodriguez

- slashdot

- smoothspan

- The Tech Chronicles

- Wired's monkey_bites



- Marci Segal


Visual Thinking

- Amanda Lyons


Social Networking/Web 2.0+ Watch


- Mashable


Visual Thinking

- Dave Gray

- Dan Roam

- David Sibbet (The Grove)

- Scott McLoud


Leadership Skills

- Presentation Zen


Strategy, BI and Competitive Intelligence

- Freakonomics blog

- Tom Hawes

- Malcom Ryder


Um... and these
- Nick Carr

- Tom Peters


Green Thinking

- Sylvia Earle, TED

- CNN Money Business of Green videos

- Matter Network


- xkcd

- Buttercup Festival

- Dinosaur comics

- geek&poke

- phd comics

- a softer world

- Dilbert




Journal Map

1/5/11 Sense and Sensibility

I think, in part, some of the bubbling resistance to the "architect" notion has come from shining a well-intended light on the other skills of the architect, beyond those that are purely technical. We bear a good part of the responsibility for that, having led into that arena, but various architect certifications have added mainstream awareness of these other dimensions of the skillset. So, for the record, the technical skillset (honed in the development of systems, and supplemented with what others have learned through patterns and other vehicles for packaging the learning into consumable form, including processes like VAP ;-) is absolutely fundamental. The thing of it is though, our experience and degrees are typically in the technical domain, and we gain this experience for the most part giving a computer instructions, and to be sure, computers have their own way of being obstinate, frustrating and then yielding, but grudgingly, to our persistently plied attentions. Programming is, after all, thinking, but thinking and trying can beguile us into more trying than thinking. Regardless, coding (even pair programming) is different than making decisions (alone or in a team) that impact various stakeholders, often many and quite varied stakeholders. Architectural design is about leverage, but it is also about (from some points of view) compromise. So negotiation. Persuasion. Influence. Leadership. And we find ourselves tumbling into a space of skills we didn't much need when being productive meant we got to have serious personal time with a machine. It is the lack of preparation for (and, frankly, often the lack of admiration for), and the make-or-break importance of, the "soft skills" dimensions of the role, that causes us and others to highlight them. But it does make for surprise for those who haven't been noticing these attributes of the architects that are effective in the organization. We so often look for role models among people who are like us, rather than among people who excel at what the job we're eying needs us to be good at! 

So, for example, if we say the architect needs to have skills in the strategy space, this can be a red flag to the proverbial bull, raising counter that this is bs of the highest order since architects do not set strategy. Au contraire! Architects set technical direction (sometimes others do, but on what basis?). And direction setting is strategy is it not? And technical direction shapes and constrains business direction. (Think MySpace, and you'll see my point. Yeah, it's an extreme case, but extremes make a point extremely vivid.) So technologists need to savvy up to the impact of technology choices that create direction that impact what is the effective (emergent) business strategy. Managers too. That recognition, then, means business strategy setters do well to take input from architects (at the relevant level of scope/seniority) who understand technology capabilities and think strategically about technology trends, and technologies in other domains that can be leveraged into capabilities in their business domain, and so forth. Value, after all, is created through integrated "bundles" or webs of capabilities. Ostriches may not stick their heads in the sand to avoid acknowledging threat, after all, but we do if we don't acknowledge the link between technology strategy (and implementation) and business strategy in this age where business systems and the products we create are intrinsically socio-technical.

Ok, perhaps you're nibbling, not quite persuaded, but some of your reservations are being shaken up just a little... Perhaps, then, you counter, this is all very well for senior architects, but not entry-level application architects? In The Art of Change: Fractal and Emergent, we argue for viewing strategy and architecture in fractal terms -- emergent too, but importantly, in pools of strategic influence that vary in scope/impact. So we think in terms of product or service strategy (narrow scope), through increasing scope to cross-cutting strategic initiatives and corporate strategy (enterprise scope).

Well, how do you gain strategic competencies? By acting strategically -- by thinking in terms of creating sustainable value. Sustainable in... yes, the refrain if you please -- sustainable in every sense of the word from technically to economically and environmentally to morally and personally. I'll burn this in, I will, I will! ;-) And then, just think what a transformation we'll have, when ripple by ripple ever more architects have taken moral ownership for dealing

Oh, I'm kidding, but only about my role in initiating a gentle wave of change -- for many before me, and many besides me, are tipping these ripples of change. I only add my voice and "gentle" wallop of words... ;-)  

Uh, I didn't expect that to go there... Let's see, where was I... Ah yes, addressing those just transitioning into the architect role at a narrow scope of influence and decision authority... Or, more likely, those who are concerned for those contemplating or assuming the role. The former being unlikely to have gotten past the child-like/ish/girlie manga at top of this page. ;-) Ouch! Right? Stereotypes (yes, Procrustean frames) are damaging and unfair. I didn't really put that image there as an amulet, truly. I only tease myself with that reflection, because I know that my (delightful?) choice of New Year's greeting will have that affect on some people (but not people in a specific role, just busy people needing to manage their attention with quickly cast assumptions based on the obvious cues or signals presented to them). My teasing within teasing (of myself) is about the ironies implicit in wanting an audience that values what I do, but providing very little to attract an audience; rather providing all the cues and substance that would put an audience off!! [Allowing this paragraph within an entry that otherwise might have some small impact, for example, undoes any likelihood that someone could recommend it. ;-)] But... since no-one else will read this... I'll ask just you... isn't it genius indeed to title this post 'sense and sensibility" -- a reference to Jane Austin's first novel, exploring our various follies and foibles especially stereotypes or group expectations?  (Though set in the early 1800's it reads well today, for example, if you translate the conceits and fashions of the day into those we encounter in the technology space). Ah, but the novel is also about the goodness which in most of us manages to be ever resurgent despite our repeated lapses into foolishness. Ok, ok, I mean genius in the Elizabeth Gilbert sense, or Sara's "voices in my head that are not my own." Voices that arise out of the parade of minds we've encountered and allowed to bed down in our own, fathering thought children... Uh, let's get back to the point. Not that we diverged from it, those with highly tuned sensibilities will note. ;-) Huh? Well, the point is that there are notions of the architect role that delimit it as a technical role. So, simply a hat. So a hat everyone on the development team can wear. So no need to make it explicit. So... no leadership. Erosion. Ball of mud... Yes, it is a technical role. But it is more -- it involves bridging, translating, synthesizing, direction-setting...

The point is that we need to start seeing the systems we create in strategic terms, and partner with business leaders at the relevant scope to create strategies that create value for customers, the business, developers, and others in the value network. But not just any value. For, given limited resources (talent, time), we have to make choices. Strategic choices. Choices that impact sustainability -- competitiveness in tactical frames without undermining future viability (technically, competitively, organizationally, socially, personally, environmentally). Personally? Well, for example, high degrees of "technical debt" (a nice businessy sounding gloss for a "#load of mess"?) create high-stress work for those who will inherit the burden of system evolution. High stress? Ever had to make a change to a "hairball" that your business depends on?

Technology has woven itself in the very core (in Geoff Moore terms, too) of the business. Our value networks and businesses are becoming ever more "monitored" (analogous to patient monitoring in hospitals) with information gathering devices and artifices, and turning the deluge of data these "sensory inputs" create into intelligence-led actions is a matter of strategic thinking (the deluge must be mastered or the utility will be washed out -- that classic "information costs attention" Herbert Simon quote comes to mind) to channel, direct, focus excellence in tactical deployment. Just processing more data, no matter how academically (meaning outside of the context of our business) impressive our analytics, isn't going to make us smarter without making smart choices about where to focus attention and resources. On and on we could go with examples, but the point is that our businesses depend ever more on technology, and this technology is ever more interconnected because that too creates business value and opportunity, so the wicked problems of business systems reach tendrils ever deeper into other systems and all of this is strategic -- make or break for the business and a matter of setting vision/direction (which is a matter of making choices about what value to pursue in the context of alternative, competing demands on limited resources), strategizing on how to realize the vision and leading the execution of that strategy.    

Architects bring technology savvy to the business opportunity-seeking, framing, leading partnership of the strategy team (at the relevant level of scope). Which means it behooves the architect to have good strategic sense and sensibility -- blink intuition, and smarts born of paying attention to and learning about the business impact of technology, technology directions, and so forth (this gets too long already), relevant to the products/services and markets or webs within the value chain that the systems the architect designs fit into. Well, it behooves the architect if his/her organizational context allows him/her to accept the challenge of creating sustainable systems. It is certainly true that in many organizational contexts the (so-called) architect's role is circumscribed to technical heroics, fighting on-the-line fires and saving the day -- today. Each and every day. Or coding the really challenging pieces of systems. But these aren't architects in the sense of being responsible for system integrity (design and structural integrity). These are technical specialists with admirable and crucial technical know-how. Yes, architects must have that too, and may well play this role, (importantly) keeping their hand in the game and maintaining high technical cred on the team. Just, not all the time.  

Mess management is an allusion to Ackoff, who popularized (and perhaps coined) the term. "Wicked problems" is attributed to Horst Rittel.

Well, much (too much) to do...


1/6/11 Software Architecture Workshops

4-day Software Architecture Workshop in Palo Alto/Los Altos, CA on March 21-24, 2011. Note: There is an early enrollment discount of:
- $400 for enrollments completed by January 30th, 2011
The early enrollment discount is there to try it to encourage enrollments soon (if we can guarantee a higher participant minimum that impacts the venue pricing, and in Palo Alto, that signifies).

The Embedded System Institute is running our Software Architecture Workshop (with Dana Bredemeyer instructing) in Eindhoven, The Netherlands on March 29 - April 1, 2011. Last September this class was full and waitlisted early, so enroll soon!

It is always good to have a spectrum of experience in the workshop, and senior architects do typically find the workshop valuable. They offer perspective, bringing in insights, guidance, stories and lessons and validating the importance and relevance of what we cover in the workshop. Mark Mullin was one such senior architect and he characterized the workshop as "collegial" (on LinkedIn) and I really like that way of putting it. I tend to use the crucible word, meaning everyone gets to put questions, content, stories, lessons, guidance into the "crucible" of the workshop, providing a rich mix from which participants compound and draw forth the insights that illuminate their path and their work as architects. All voices are respected and encouraged, and that level of working in the large group and small teams is an enormous part of the value of the workshop. It is a great time to back out of all the pressures of the job, and reflect on what works and what creates impedance and how to be more effective in making architecture decisions that truly make the business more successful.

While our decisions are technical, what makes them fail or succeed is very often not! Wrong decisions may be a matter of ill-advised technical choices or a matter of not getting what the real criteria are (like political crud that has tendrils wrapped all over the decision but which those of us with weak political sensors just aren't noticing, or we think that pay-check drawing folk should just get on with doing the rational thing -- you know, what we have decided). Or the right decision may be misunderstood or balked at -- for many reasons, from orneryness and habitual push-back to real concerns about the side-effects of the decision. Etc. Stuff. Happens.  So we work on all these fronts--technical, business, organizational and personal effectiveness. Working with very carefully selected "Pareto" tools so the technical decision process is supported, and we realize a minimalist architecture that is good (technically sound), right (meets stakeholder goals, addresses--on balance, or reshapes--their concerns/frustrations/aspirations, etc.) and successful (is actually realized and shows value--from early days through delivery through a vibrant evolution to obsolescence by the next generation).

Well, hopefully that has you eagerly rushing over to sign up. But remember, bring some of your colleagues along too. They will see what you are trying to do, and why you do what you do, in a new light, and it creates common language. Our explicit goal is to inspire and enable, so when we all (participants have to pitch in) succeed, you leave impassioned and with an enabling toolkit and organizing models to guide the choice and application of the tools. Or... something like that.

But if that didn't do it. Let me remind you. The workshop is in Palo Alto (actually just on the border between Palo Alto and Los Altos) -- yes, the Bay Area/Silicon Valley. You can bring your family (it's a Residence Inn, so family-friendly). There's plenty to do in/around Palo Alto -- visit Stanford and even if you don't make it to the art museum during opening hours you can go to the Rodin sculpture garden, and to the bookstore (and see Rodin's Burghers of Calais; The Thinker is on loan in North Carolina, which is too bad because as you see from the top of my page, The Thinker is important to my identity). Visit the Computer History Museum in Mountain View, and see displays in the Gates Information Science building at Stanford. And go up to the city (San Francisco) or cross the Bay to Berkeley (go to Bette's Oceanview Diner for brunch--no view, great food). Head over to the coast (we lived in Moss Beach and can give you lots of pointers to hikes and restaurants). Dana taught kayaking in the Bay, so can give you pointers and tips. Etc. Take the spouse off to Napa for the weekend. Whatever. It's a glorious part of the world! Dana and I will be fighting over who teaches this one, but if he wins out, I'm bringing the kids! ;-)  [Actually, Dana usually insists I do the open workshops because he's so booked up with existing clients, and he learns so much from me he thinks other architects should have that opportunity too. I love facilitating the workshops, but from time to time someone has um reservations about my quiet voice and thoughtful, non-assertive style and my spirit wilts at that, so I'm always ready for Dana to do it. Besides, I learn so much from him, I think other architects should have that opportunity too. ;-)]

Oh, and if you're totally into doing this, hopefully your manager will read this and translate it into doing more to develop and enrich the work lives of the talent (not to mention the IP embedded in their heads) they want to keep, so he/she will champion (even beg, borrow and steal) the budget to enable you to go on this boondoggle, um, I mean go to a training that will put you on a high velocity path to creating sustainable advantage through technology. ;-)

Just... don't let your manager read this. The overview on the Bredemeyer site will have to do. [Word to the wise manager (only wise manager's read here) -- let your architect think the boondoggle was your idea. Don't let your architect read this. The overview on the Bredemeyer site will have to do.]

Or... just keep reading my journal... and papers... and the book... and you'll get some of the value. But remember, conversations change the world. You will be different for entering into the lively conversation of the workshop. The other participants and I (or Dana, if he's lucky) will be different. And the world will be different, for the greater impact we'll have. Reading is a controlled interaction where we choose what to take and what to leave so we tend to do more leaving if the material isn't quite what we thought we wanted. Yes, some of that happens in a conversation but the less so, the more we enter with a spirit of goodwill and yield to the sometimes leading, sometimes following, interactive flow of the conversation.

The point about conversations in the last paragraph owes much to a conversation I was having with Dana. It will change how I talk about conversations, which will in turn impact other conversations. A good many architects expect that the confining boundaries that surrounded them in the cloven "divided by specialty" work-world (where, for example, developers don't talk to marketing, let alone customers) still surround them, and it is a big ah-ha to find that the architects who are successful are working outside those boxes, having -- yes -- conversations within but also outside the development team. Conversations change the statespace -- the content, like knowledge and ideas, and the attitudes -- of the architect and of (other) stakeholders. The architect starts to be seen differently, because the architect starts to act from a different statespace as a result of the interactions with stakeholders. These stakeholders know their concerns are being brought personally into all that must be factored, and they have a better sense of what is being weighed and balanced, synthesized and sometimes, yes, compromised but for the good of system outcomes.

We rational, objectively thinking engineering types can forget that the attitude part -- not just the knowledge and reasoned argument part -- of the statespace tends to be the bigger factor in getting things done with and through people. Including ourselves, for managing our own attitude is where it all starts. Lack of enthusiasm, goodwill and joy dulls our own ability to imagine and sculpt "clouds" into realized things. Fortunately, a lot of what we do to sculpt "clouds," carving a dream we share into reality, in Visual Architecting works on the state space -- the knowledge and decision space and attitudes, feeling, passion -- at the same time. If we do the right kinds of things sometimes with other people (sometimes alone and then together, sometimes in small groups, sometimes in large groups, pulsing dynamically) we can have the process do double duty, making formal progress and informal organic progress too.


1/6/11 Design Thinking


We may have to think at different levels of abstraction; probe more where we have greatest uncertainty and discomfort.

Note to self: According to wikipedia: "Synergy can be understood as the opposite of the concept entropy." Opposite? I need to think about that...  With increasing entropy, there may be decreasing synergy, but I'm not immediately getting that the concepts are opposite...


1/7/11 On Tilting at Windmills (The Most Important Hour of Your Year!)

Ok, if you watch this Jim March lecture-film, Don Quixote's Lessons for Leadership, and don't find it the most transformative, most you-affirming, ultimately career-enabling hour of this year... my brand of useless is indeed useless. ;-) Wondrous awe ( by Sara B.)

Now aren't you glad I told you early in the year? (And if you knew about it, why didn't you tell me 7 years ago? Huh? Huh?)

As for me, I think I was just given permission/encouragement to keep filling my wild landscapes, insane as that might seem! ;-) You know, Stanford professor emeritus Jim March is listed by many in the "establishment" line-up of "thought leaders" as their guru or mentor. I generally dislike parties (I'm introverted and outside of architecture not a social creature) and I'm late to this one, but I do like his irreverent stance towards the staid norms with which we bludgeon fellow "workers" into conformity and compliance. I guess I'm going to have to re-up on my HBR subscription so I can read what March had to say about:

aesthetics, leadership, the usefulness of scholarship, the role of folly, and the irrelevance of relevance when it comes to the pursuit of ideas  --  Ideas as Art, HBR

Although... I don't like being put through that "Procrustean treatment," so best to avoid raising the possibility...?! Wild landscapes are hard to get to for a reason, perhaps...?! :-)

It is instructive, though, how Serendipity -- you know, the perhaps name of angels ;-)  -- weaves its threads, reasserting a lesson it wants to teach if we don't at first pay heed. The other day, Daniel Stroe pointed me to Dostoevski's The Idiot and Kurosawa's film interpretation. [No, nobody -- not even I, in this case, though I am apt to -- was implying I'm an idiot, but thank you for your protest at the thought. ;-)]  I like Kurosawa's response to the reaction that the film was too long: "cut it in half length-wise!"  (Think that would work with my journal? ;-) I responded "I love the references, and the reminder that being thought a fool by fools has more merit than otherwise." That was too glib. Serendipity had more work to do on me. So, Don Quixote. I'll have to attend better.

We are paradoxes within paradoxes, we sentient creatures! How hard we try to be rational and gain control, submitting so much of our sentience to the leveling expectations society -- through our own mediation -- imposes. And even when we know, rationally, that it takes a seeming irrational advance to break with current thinking and confining convention and address something that is wrong in the world, we lash at the fools who by dint of fantasy, folly and obduracy (what in ourselves we call imagination, resilience and discipline) seek to make something different into the world. Ah, but again, balance is key. Not so much moderation as to be too timid to act. Not so much immoderation as to be cast outside society. We have to trust our sense of self, the passion that lights our will to lead, and our sense of what to do about something that needs to be done!

That phrase "through our own mediation" calls this quote to mind:

"No one can make you feel inferior without your consent." -- Eleanor Roosevelt

Well, in closing, I must just say -- gosh, I will no longer think myself audacious bringing The Wheel to IT leadership, relating it to innovation and agile, self-organizing teaming; Jim March sets the bar with Don Quixote's Lessons for Leadership!   

Image by Sara B.  The sketch relates well to Jim March's inspired use of My Neighbor Totoro in Don Quixote's Lessons. [I haven't seen all of Hayao Miyazaki's films, but I've loved all I have seen. I can't tell you how many times the kids watched Kiki's Delivery Service and My Neighbor Totoro when they were much younger. We enjoyed watching them once or twice too. :-) Sara loves Howl's Moving Castle, but I haven't yet seen it. Dana bought a toy Totoro for each kid back from Korea one year, and now the kids have outgrown them, I find I have grown into them! An emblem of imagination, indeed!]

1/7/11 On Experience as a Teacher

"This book considers the unexpected problems organizations (and the individuals in them) face when they rely on experience to adapt, improve, and survive.

While acknowledging the power of learning from experience and the extensive use of experience as a basis for adaptation and for constructing stories and models of history, this book examines the problems with such learning. March argues that although individuals and organizations are eager to derive intelligence from experience, the inferences stemming from that eagerness are often misguided. The problems lie partly in errors in how people think, but even more so in properties of experience that confound learning from it. 'Experience,' March concludes, 'may possibly be the best teacher, but it is not a particularly good teacher."

-- Amazon product review on The Ambiguities of Experience by James March, 2010

You know, someone should tell Jim what I say: Lessons are best learned from experience--someone else's.

Yes, there is some strength to the argument that architecting skills are learned from experience--but the lesson is always much less costly when it is from someone else's experience!  -- moi, Bredemeyer website

"Always" is one of those extremes that are valid only in extreme cases, but I'm sure you get the humor in my extreme-ly vivid quip. But what I mean is that we learn much also by integrating "knowledge" (the synthesized lessons of those that went before us) into action, into learning by doing, and then we learn still more by reflecting. And we learn from those who reflect on what is learned by doing, synthesizing and distilling and organizing knowledge (from the very practical and task oriented to the more abstract and orienting) into useful forms. We progress by this process of integrating and extrapolating/projecting and extending/reapplying in new ways, doing/trying, and reflecting/extracting/organizing/relating/synthesizing and more. Not all learning by doing. Not all "ivory tower" learning by reflecting, scholarly investigation, and scholarly discourse in ideas and their application and relationships to what is known. Craftsmen play an important role in showing what can be done with acute attention to learning by doing, by engaging hands and head. Scholars play an important role too. And others who pulse more between doing and reflecting.

This looks interesting too:

How Decisions Happen! Happen -- that's not a chance word. I need to read it -- soon!

So, architecture documentation -- is that how we take blink intuition, emotional content, political engineering and reasoned analysis and allow decisions to happen, then cast them in rationalized terms...  and communicate them to people who will rely on blink intuition, emotional content, political engineering and reasoned analysis to grok them... ? That sounds both easier and harder than I'd thought!


1/8/11 Sarandipitous Images

The artist:

The harp is often drawn as the instrument of angels. Though Sara's only being playing for a year, I can hear why!

And her art:

Bliss and serendipity. The perhaps names of our internal and external angels.

Buckminster Fuller's motto was "Dare to be naive." We can get so worldly wise, so silted up with experience and know-how and know-better, and adulterated by cynicism we stop reaching for the "unachievable." What the skeptic thinks a folly to try is just a breakthrough opportunity someone will make the most of. If we can put aside our sophisticated views and just dare to be naive, to imagine, to dream, we open ourselves to what is possible.

"Why should you want to give up a child's wise not-understanding in exchange for defensiveness and scorn, since not understanding is, after all, a way of being alone, whereas defensiveness and scorn are a participation in precisely what, by these means, you want to separate yourself from."

-- Rainer Maria Rilke, Letter 6, Letters to a Young Poet

I was struck also by Lights Pretend lyrics:

Once in a while I act like a child to feel like a kid again

It gets like a prison in the body I'm living in

Cause everyone's watching and quick to start talking, I'm losing my innocence

Wish I were a little girl without the weight of the world

It would be nice to start over again

Before we were men

I'd give, I'd bend, let's play pretend

Remember the times we had soda for wine And we got by on gratitude

The worst they could do to you was check your attitude

Yeah when fights were for fun, we had water in guns,


It's not going to be long before we're all gone with nothing to show for them
Stop taking lives, come on let's all grow up again...

Childhood is an amazing thing, and innocent unadulterated optimism hard to sustain, but we can--do need to--skim off clouding pessimism, and maintain an open-hearted belief in the goodness in people! We can dance amidst all that is real, see it in its squalor and its glory, see the tawdry and the magnificent, see all of the contrasts between smallness and greatness, and know that such good is possible.  Always. And at any moment!

"the writer is delegated to declare and to celebrate man's proven capacity for greatness of heart and spirit—for gallantry in defeat, for courage, compassion and love. In the endless war against weakness and despair, these are the bright rally flags of hope and of emulation. I hold that a writer who does not believe in the perfectibility of man has no dedication nor any membership in literature." — John Steinbeck, Nobel Prize Acceptance Speech, 1962

We just have to disabuse ourselves of know-better! Of defensiveness and scorn. [And the necessity of writing full sentences. ;-)]

There are endless possibilities out there!

1/16/11: My father set context for my childhood with his "positive thinking." He was joyful in spite of his troubled life and wanted to do things the good, right way, even when it was the hard way. So he did odd things like insist on farming his smallholding (in after-work hours) with no chemicals. No pesticides. No fertilizers. Remember, that was when I was growing up--that is, before organic was a "thing"; that is, before you could charge a price premium to cover the additional labor and crop risk. Last night I watched Cross Creek. It is the kind of thing that whose who cast movies that way would call a Q<= movie, but I wanted to do something that was a celebration of women, at least my kind of woman, and picked just that movie (sorry, but sometimes the world is a tad mean and I just needed that). It was what I hoped, and it was also a celebration of our connection to the earth and a reminder of the ways in which my father was great.


1/8/11 Visualizing Why We Need Architects


Its what you do next that counts...

Image: When the Tiger Woods hoopla broke loose, I wondered what Accenture would do. This (above) was in the airport in Chicago (photo taken by Dana when we passed through on New Year's Day, 2010)...  I don't know if it was just serendipitous timing, but it made us laugh and grab for the camera!

The image speaks volumes doesn't it? When you're in the rough, what you do next counts. But who wants to be in the rough? So it's not what you do next that counts -- not when we take a long view. What really counts, is what you do to not get in that spot. That's integrity. It's hard. It's a matter of tough choices. Of pro-active action, and at any misstep or fumble, ever drawing back to the path we set true to our identity (mission, values, sense of meaningful purpose, etc.), our moral compass.


1/8/11 Musing About Muses

Active reading engages us in a conversation between the voices in the writer's head reflected in the writing, and the voices they set conversing in our head. Even people long dead live on in their writing for reading brings their voice alive in our heads. Natalie Merchant confessed to an adolescent girl crush on Robert Louis Stevenson, adding that still today if he was to walk into her life there'd be trouble, while Tim O'Reilly tweeted "If you want to fall in love with the mind of RLS, read Home From the Sea." Ryan North, of dinosaur comics, heads his comics blogroll "some comics I would TOTALLY MARRY." I see a meme here, and I think it is playfully yet insightfully talking about the powerful way we experience this interaction of minds and how we incline to what we enjoy reading. Reading happens in our heads where we most experience ourselves as sentient beings. It is possible we'll take someone into our heads to disagree with them, but for the most part, at least in the reading we do as part of our "awe-struck seeking" we're going to invite in voices we respect and like.

I don't go in much for "gurus," but lean rather to the notion of muse. It is perhaps a problem of (mis)interpretation on my part... Still, I think there is a danger of placing and being placed on a pedestal that is damaging to the seen and the seer. A muse, to me, is one who we allow to instigate insight and inspire us. We don't venerate them because we know our own role in the building of our self, our understanding and capacity to build something great in the world. Yes, we allow our muse to bring something new into our thinking, so we have new insights and even extend the boundaries of our thinking. But we do this ourselves. A guru lends us his wisdom; a muse instigates and stokes our own. We pay deference to a guru; we pay respect to a muse. A muse muses, and we use their musing like yeast in a bread (raising our own musing). But we have to be pervious, to be susceptible to a muse. 

Now, one could wonder why anyone would choose a muse who is too much like oneself. Sure, one wants a muse one likes to engage with, but too similar a voice only confirms but does not help us bring something new into view, does not provide fresh reflection only images we've already seen in our self. It is validating to see that confirmation, but we must also be surprised by our muses or they do not serve to help us extend ourselves.

Muses risk opprobrium--they wouldn't be doing something useful if they didn't bring something new into our experience, and a change in view will have its detractors. Simply writing or speaking out risks detractors! And when their thought leadership puts them in peril, we may see them as heroic. But better, I think, for the muse and those who allow the muse to be one to them, to brook no pedestals.

Oh, and to quiet a sniping voice in my own mind, let me say: To write a muse off as some kind of self-help mumbo gumbo is to dismiss the tradition of learning from others, the tradition of the resourced intellect that leverages the great explorations and discoveries of other minds to make more within itself.

1/10/11 Marvin Minsky

There's a delightful interview of Marvin Minsky on MIT's Infinite History (oral histories) site.

Of Richard Feynman, Minsky said:

-- if you think of doing something he'll say, let's do it. And then we'll do it the next day or right away. And usually get anything done-- to get anything done-- you have to convince a lot of people and make a plan and so forth. But I've worked with a few of these people who say, well if that's a good idea maybe, we can do it tonight instead of next year. So until the 1980's, I never wrote a proposal. I just was always in the environment where there would be somebody like Jerry Wiesner of MIT.

Nice as it is to hear Minsky tell his story, I can "hear" him through the words of the transcript... and I found that if I forward the video to the end, then I can read the transcript at reading speed. Phew.

I lol at this:

MINSKY: Senator Mansfield who was a great liberal decided that the defense department might be a dangerous influence and he got Congress to pass some rule that the defense department you can't do basic research. It should only support research with military application. It's a great example of whatever you want to call it.

That is such a great way of putting it! Of everything that might come to mind given this story, this is a great example of that! Given that, it only got funnier when the interviewer tried to be helpful (and tactful or pc), adding:

INTERVIEWER: Unintended consequences--

Minsky would have none of that mincing:

MINSKY: Or shooting yourself in the head.

Of abstractions in learning, Minsky said:

Because you can think of any theory of learning as saying you've had a lot of experiences is there a sort of higher level, simple thing that they're all examples of. And Ray Solomonoff invented this other way of making generalizations. ... Ray Solomonoff's theory said if something happens you must make a lot of descriptions of it and see which description is shortest because it must have the most significant abstractions in it. Like if you could have a short description that gives us the same results as a long one it must be better or whatever.

MINSKY: ... this Occam's razor or finding the simplest theory worked tremendously well in physics and it worked pretty well in some other sciences. But in psychology it does nothing but harm. And a simple reason is that we already know that the brain has 300 or 400 different kinds of machinery. And they're each somewhat different. We know how three or four of them work like a little bit about the visual system and the cerebellum. But we don't know how any of the dozens of brain centers work in the frontal lobe and the parietal cortex and the language areas and so forth. But one thing we can be sure of is the brain wouldn't have 400 different kinds of machines unless they were specialized and behave in different ways and do different things.

So The Society of Mind starts out pretty much in the opposite way and says, let's take all those things or a lot of the things that people do and try to find simple explanations for how each of those could be done. And then let's not try to find a simple machine that does all of those but let's try to find some way that a few hundred of these different things could be organized so that the whole thing would work.

That's kind of like designing a software system in terms of societies of mechanisms.  So... I'd like to know what Minsky has to say about analogy, and analogical reasoning. Well, I need to read both books. I took an AI class way too long ago (late 80's). 

1/10/11 Visual Architecting

The VAP software architecture decision model provides an organizing structure for decisions and the models and descriptions that explicate, rationalize, contextualize, defend, advocate, and guide the implementation of these decisions. It provides guidance and directs attention so that we don't miss crucial aspects of the architecture, but without being directive and prescriptive. Rather it allows for an organic process that adapts to system and organizational complexity and uncertainty, challenge and risk.

With the Visual Architecting Process map, we see how threads of reasoning cut across design choices or decisions and the views that express and contextualize many of these decisions -- we express, think about and communicate many of our design options, then choices, in models -- drawings of the design we have in mind. These begin as informal sketches, reflecting early, formative ideas. This format is a cheap design medium for exploring options, in good part so that we can find promising or tricky areas so we can selectively direct attention to opportunity, risk or uncertainty/"big buzzing confusion" that we need to resolve better to assess our direction. Schematic illustration of iterations through bands the decision modelThen, as our design ideas mature, we mature our rendering of them, adding precision and formality, and disambiguating them so that we can better presume consistent interpretation (without repeated personal intervention to ensure design intent is communicated). Of course, this is itself a process of discovery, of design, and as we add detail, we find ourselves reconsidering earlier design decisions.

This highly iterative process, and necessary willingness to hold the design in creative suspension, can appear chaotic to the outsider. We're making choices to move forward, but recognizing them as stakes in the ground that help us see what needs to be changed, which makes for backtracking. We're exploring ideas and options. We're diving into detail in areas we find important to clarify further, to find an appropriate approach at a more strategic level. However, with the Architecture Decision Model and an organic, iterative process, it is chaordic. A hybrid of chaotic (imbued in the nature of the creative process) and orderly; of organic and (just enough) higher ceremony process.

An organic process is one which adapts and flexes according to the context, the system, and it's architect(s). Much of this organic nature comes from recognizing that the architect decides which decisions and elements of the design are architecturally significant, when it should be addressed, and how (from "thinking it through"/envisioning it in the mind's eye to "modeling out loud" to ... using a pattern to ... building a paper mock-up or a code prototype ... to incremental development).     

Architecture decisions are those that the architect judges make or break for the system. They have to do with game shapers and game changers. With strategic impact. With design excellence and system integrity. And they may generally be characterized as those have a high cost of change, but it is, I believe, important to highlight those that have to do with the strategic (impacts competitiveness) approach. If we set out in the wrong direction that will bear a high cost of change to correct, but chances are good we won't know until we outright fail. This is because we will get delta feedback on an expectation set we start to shape and confine according to the direction we've chosen. These are the big failures of imagination, of missing the mark.

Image: Dominiqu Studer entries discussing VAP:

An alternative point of view: how to write good code.

Image source: Dominiqu Studer, My Four-Leg Walking Machine. See the variable speed gear animation, and the walking machine--it's way cool! 

Why this image, in this context?  It's a better (lending more organismic motion) visual analogy than the traditional cogs that I used (with some reservation, but I relied on people knowing that our approach is in no way mechanistic) in Getting Past ‘But’: Finding Opportunity and Making It Happen, 2008. That paper is about agile architecture.

Here's another image for Getting Past But:

If we put the architect behind the elephant, we might as well give him a shovel because all he can do at that point is damage control...

And the longer we take trying to get it right, the higher the cost of being wrong!

It doesn't do to rub our hands in self-congratulation if we're "doing agile" but merely delta incrementing our way to a entirely wrong solution for the market. If we don't explore just enough before we get resources and egos vested in a solution concept, the tack we start down (whether waterfall or agile) becomes largely self-confirming--for those involved. The product manager. Beta users. Etc.     

1/10/11 Chuckles, Perhaps

My family is collecting a set of mis-spokes -- mine.

Ok, so you know Dana talks with his hands. And eye contact. Even when he's driving. One day I blurted out: "Keep your eyes on the wheel and your hands on the road." Fortunately he is a superb driver, even when laughing!

Seeing a mule deer in Bryce Canyon that my family hadn't spotted, I exclaimed "There's a there's a!"  A few days later, playing 20 questions, my son said "Oh, I've got one." and Sara said "Is it bigger than a microwave" and he said "Yes!" and right off, without a moment's hesitation cued only by his demeanor, Sara said 'Is it a 'there's a"?' and he said "Yes!!" in a gleeful tone. Ever since, a deer of any sort has been known as a there's a. It has spread to my kid's friends. In time, who knows, you'll be calling them there's a's too--though unlike other people, you'll know why!

Tonight, in gentle earnestness I said "Please don't talk with your mouth open"--meaning full of food, but my family was totally onto that and immediately started the "there's a there's a" and "keep your eyes on the wheel and your hands on the road" refrain.

But, as much as people misunderestimate me too, I've got nothing on former President George W. Bush.

1/11/11 Quixotic Doesn't Fly!

Image source: wikipedia,, my Quixotic submission to SATURN didn't fly. Naturally I half-expected that, and perhaps it wasn't fair to make the tutorial team choose or reject so playfully Quixotic a proposal.    

But think about it: The art at the technical heart of architecting that makes it come pulsing to life. Wouldn't that be a great tutorial? The art that we engineering types put in boxes, but we mean so much more than boxes! Yet how do we draw what we mean when the medium we construct with is itself so abstract? So we draw boxes, and use something akin to what artists and poets use--something akin, that is, to what great engineers, innovators and inventors use! We use sketches, diagrams, models, schematics and use, advance on, and shatter precedent. Yes. But more! We use analogy. We use abstraction. We use compression. We use patterns (drawn with boxes, leveraging analogy, abstraction, compression,...). We use iteration. We make meaning. We use conceptualizations to create and to communicate and these conceptualizations are not wisps of dreams, even if they begin there. Boxes--itself a metaphor. Boxes and relationships. Inter-relationships building synergy. By applying accumulated knowledge and experience and reasoning we make our designs a matter more of intentionality than mere accident, and because we have so reasoned, we have the foil upon which to improve our understanding, as we consciously evaluate our designs under the stress tests of execution and evolution. Ah, these boxes which may be easy to underestimate, are so powerful, for they enable us to visualize what is otherwise hard to render to support reasoning, communication, recording and improving. They are expressions of experience, of know-how, translated into new forms which we sketch, test and improve, and build, test and improve, but to do so we need to communicate and advocate and impassion. All this the glorious defining art at the technical heart of architecting! 

Image source: Don Quixote and his sidekick Sancho Panza, by Gustave Dore. (January 6, 1832 – January 23, 1883), wikipedia

Look, I know full well you could say that is just my nuanced way of talking about what architects do anyway! Ah, but the just-so of what you might call my nuance is re-orienting. A good part of our field was never enthralled, while another good part became disenthralled, with visual modeling. Still others in our field have never quite understood the value of the conceptual architecture. As important as conceptual models that orient and organize are (whether for a system or a field of practice), there is more to this--much, much more to this. Yes, it has to do with drawing boxes and lines and framing conceptual architecture so that we see its meaning. Drawing. Boxes. Framing. Meaning. I could go on. But that would be the tutorial.   

I am disappointed. If we don't get our heads wrapped around this now, how do we "architect the future?" So, my heart verily sinks. Being spirited in a world of leveling forces is hard to sustain. Life is so much about boxes. About living with stereotypes and circumscribed roles, and yet managing to transcend them without losing the good faith of those who need to put trust in you. For a tutorial about seeing our boxes in a fresh way, I chose to be playfully unstereotypical in the outline for the proposal. Well, gosh, I guess that makes me a modern day Don Quixote. Looking just as foolish. In a few centuries someone may do a leadership movie about me. ;-)

In sum: Tilting at windmills isn't all it's cracked up to be. Those giants fight back with merciless objectivity! ;-) So, on second thoughts, don't watch Jim March's video, and do not, do not, pay attention to me!"Architects must have self-repairing egos" -- Dana Bredemeyer

Unless you want to put something to rights in the world. In which case, you are your own kind of "different." [Then, remember that many great leaders are the greater for the leveling forces they transcended. Steve Jobs is a case in point. He was fired, but he came back to prove himself--again.]

As for Dana, that's the first time he has had a tutorial rejected; he should be more cautious about doing something (about boxes or anything else) with me! Should, but won't.

As for SATURN, I well know the challenges of creating a balanced program that will serve its audience well. This has to mean that the tutorial line up is truly amazing, and that it will be a conference that the audience enjoys and benefits greatly from. How very exciting!

"Architects must have self repairing egos."  -- Dana Bredemeyer  

1/11/11 Not Those Boxes!

Architecture encompasses decisions but it is about creating designs, and expressing designs. Designs that bring experience, reasoning, precedent and intentionality to bear so we obtain desired system outcomes. As I provocatively said in the tutorial proposal, we need to get to the point where we insist that we draw these designs. I'm not, for example, discounting the importance of the decision to use Java versus C# and the cascade of environmental choices (and subsequent enablement and constraint) that hinge thereon. This is not about design views or documented decisions. We simply also need clear mechanisms to gain cognitive traction on designs, because the complexity of our systems and systems-of-systems predicates that we do. These boxes, the ones we clarify, just got more important, didn't they? Our designs and the views that render them encompass many design decisions. Our models and descriptions explicate, rationalize, contextualize, defend, advocate, and guide the implementation of architecture decisions. And, as I noted journaling in 2006:

When we do this, we also help educate the engineering community, sharing the experiences that shaped our decisions. Only when we document our reasoning like this, do we make our knowledge explicit and shareable. Further, it makes us more careful, because we leave a record that can be assessed and debated.

In Philippe Kruchten's slideset or Grady Booch's frameworks and views paper, for example, Visual Architecting or VAP is overlooked. But in this slideset titled  "Software architecture documentation in the real world," Markus Volter says of the "4+1" model "Not too much used in practice" (slide 70). Well, I conclude it all depends on the slice of the world you get to see! Really, I think a process should be organic and highly adapted to the team, their system and their context, which is to say, it should be "homebrew" with strong begging, borrowing and stealing from neighbors, friends and trusted advisors!! We learned this with Fusion. Then its the team's process, whatever they want to call it. Recognizing this, we tried not to give VAP a name; I've told you already. But we were backed into it. Hence, Visual Architecting or VAP. Fortunately not ignored by architects! So quite influential.  Oh, another point of history. We first presented our Software Architecture Decision Model outside HP at a COMDEX conference in about 1997. Our Software Architecture: Central Concerns, Key Decisions paper has been freely available on (and very extensively downloaded from) the Bredemeyer website since 2002! Etc. Of course much has evolved, but the cornerstones proved well-placed and durable. We have foreshadowed much of what has transpired, and I think the "something about boxes" direction will do so again. ;-) Well, it'll just have to be the book that lays it on you, won't it?!  ;-)   

Sometimes the things that feel really bad when they happen, turn out to be the best thing that could have happened.

Oh, but I should tell you I'm smiling! I might "crash and burn" 'cos I push limits, but I have a happy tolerance for myself. A sense of humor that is well accustomed to laughing at oneself is, I find, a very necessary antidote to the travails a Quixotic adventurer finds herself in. :-) No boundaries pushed, no boundaries extended.

1/12/11 The Awesome Habit

To paraphrase Marvin Minsky's theory of how the brain thinks, we set goals, compare the desired state to the current state, create a strategy, and then our internal critics go to work as we make progress towards the goal, doing the course correction thing. Now, as you know, I have very active internal critics (who do a major victory dance all over my ego when someone else, directly or indirectly, criticizes me).

What makes that work well for me, counterbalancing all that, is that I also very actively look for and see the good, in the large and the small, in others, in Nature, in the world we create, and in myself--what I build in myself as I interact with eagerness and joy with other minds and ideas and the small and great glories in man and the world.

If we want to create artificial intelligence, we have to figure out how to create affirmative intelligence. And yes, this goes for people too. Them bots are catching up, and we need to stay ahead! ;-)

"Like water wearing away at rock, your small daily habits have profound long term consequences." -- Ali Ghafour, comment on TED

It would be unhealthy to habitually only wear-away at, to always chip and chisel, even if it is with earnestness to improve what one does and creates as one struggles to be good and do good, and fulfill one's aspirations. We also need to habitually build up, affirm and appreciate and be flooded with joy! In part, directing this inwards, but for the most part directing this outwards. We do, I believe, truly need to embrace and be happy with our own good qualities for we build them at great cost of time and attention--critical attention! But if we only did that, we'd float out of touch on the balloon of our own self-importance! And seeing the good in others and in the world is a free and healthy rush of expansive joy. Better than coffee! Well, maybe as good as coffee. Or chocolate. ;-)  We have that fridge magnet, remember, that says "Chocolate is proof that God wants us to be happy!" Affirmation, or confirmation, of good within and good in deed and good in our daily experience, is happy-making too. And I think there could be few epitaph's better than (she or) "he made people happy!" It would take considerable Quixotic optimism to do that, to make that part of our personal mission, though, wouldn't it?

Get message inside! (Bloomington has great sign humor.)

Joyful affirmation of our wondrous life in all its dimensionality--and a sense of humor--go a long way!

1/12/11 More to the Core

In case you're drawing critical conclusions from my playfully "unboxed" tutorial proposal, I can do "business as usual" too. Like this overview for a VAP seminar:

In this seminar, we present our approach to architecting, covering the visual architecting process and the architecture decision model that provides an organizing structure for decisions and the models and descriptions that explicate, rationalize, contextualize, defend, advocate, and guide the implementation of these decisions. The process provides guidance and directs attention so that we don't miss crucial aspects of the architecture, but without being directive and prescriptive. Rather it is organic, in that it adapts to system and organizational complexity and uncertainty, challenge and risk. The process is iterative, and a key value is using the cheapest possible artifacts (even sketches and diagrams) for exploring stakeholder value and addressing architectural challenge. So we will explore the value of visual modeling, and building on experience including the use of patterns. We will talk about the key concerns that architecture addresses, and present fundamental principles of architecting.

Of course structural integrity is pivotal. But while our decisions are technical, what makes them fail or succeed is very often not! Hence a broader concept of design integrity is embraced so that we realize a minimalist architecture that is good (technically sound), right (meets stakeholder goals) and successful (is actually realized and shows value--from early days through delivery through evolution of the system).

So, would you want VAP straight up, or unboxed? 

1/13/11 Mind and Hands Building Meaning

Shaping meaningI was reading about Rilke yesterday, having stumbled by an unlikely path on his Letters to a Young Poet. Anyway, it struck me that this poet was attracted to sculptors, to people who observe closely and give physical shape and expression to what they see. The bare-faced direct reality, and the interpreted reality they sculpt into meaning--meaning they make possible, but with which we interact to make our own sense of it. 

It is perhaps flowery and a stretch to relate this to things we design, but when we embrace that stretch, we embrace the necessity of observing and making sense of some realm of the human experience and what needs that presents, as well as the necessity of interpreting what we see and forging a new reality in our mind and then in the built world.

We tumble through these interactions. For example, give your daughter a Mac, and she wants a sleek white printer. These cascades are so iconic they are immortalized in just such a delightful children's story. One thing creates a space, a need, for another. This isn't a "requirement," it is an interpretation of a desire. We look across desires, and figure out what need that expresses and whether there's a viable business in it.

So, you wring your hands in despair at me, and tell me not only is that "requirements" (read out of the architect's scope or charter) it is in early conception or ideation. And then I wring my hands in despair too, because these processes of observing and making sense of the need and an approach to its solution, applying intuition and emotion, knowledge and analogy, reasoning and judgment, all these and more come together again and again whenever we are designing--the experience as perceivable by the user, or the guts that shapes the experience of various stakeholders (most directly developers now and over the evolution of the system, but also users and the business, now and into the future of new/evolving uses and use contexts).     

We create with our mind-hands in this field of software. We are like poet-sculptors. We give thought physical expression. And we run into trouble when we think this can be done without creating meaning.

What is the meaning of a USB stick? A USB stick? A little utilitarian piece of hardware with its invisible threads of enabling software. What does meaning have to do with it? Bear with me a moment, pretty please. Ok, what is the meaning of a USB stick? Compact backup that allows crude "failover" if your laptop croaks? [Professionals on the road.] Compact portability between devices not (conveniently) connected? [Kids transferring homework between home and school.] "A flash memory data storage device integrated with a USB (Universal Serial Bus) interface," with ever more capacity, cheaper? [Continued business, and jobs for your team, if you can drive the capacity-cost curve, leading or at least matching competitors.] Ah, back up a moment--where it is "Kids transferring homework" how do we refine or add meaning to create distinction? For a geek (like my son), size matters. Indeed, for many it is a personal stamp in conscribed world where personality has fewer options for physical expression. Read opportunity. Now a "dove of peace" or "save the planet" becomes more important than company logo on the scant space the compact stick affords! You just transferred pressure to out-compete in the neck-and-neck race of bigger-cheaper to the skin of the thing for a chunk of the market. This is marketing? No, this is design and marketing plays a crucial role. As does manufacturing. But what I'm getting at here is that this is about meaning and it is about the interaction between guts and skin. This is moving stuff into and out of, across the boundaries--something you can only do if you see architecture (or strategic design decisions; at this level system design not software) as something that crosses boundaries. And, yes, at this boundary it interacts with marketing. Because meaning is not what we tell the market (though we can impact perception), it is about what interpretations and sense and uses we afford, what we allow the system to be open to. This is design, and skin and guts factor.

When we design mechanisms, we're doing conceptually the same thing. We're observing and discovering the need for the mechanism, we're using imagination and experience, including analogy to draw experience from another quarter, to create something meaningful. Important and valuable, yes. But also imbued with meaning that we can communicate--this does this, by this means and this is why it is meaningful to the system. Now at this boundary we're interacting with developers because as soon as we consolidate how something (addressing a cross-cutting concern, or delivering a capability) is accomplished in the system into a mechanism we impact how developers work.  Architecture is about working across boundaries, which means across "turfs" and this means treading softly on people's dreams and egos but also inviting them to build dreams and meaning together. 

What is important to understand, though, is that we are making the meaning. Up and down the system we are making the meaning, and we can translate or transfer, move around, the associated complexity, challenge and risk. We can push it outside the system (reduce the scope or make it someone else's responsibility/opportunity), we can push it into the future (deferring complexity or building "technology debt"), we can encapsulate it and shield the rest of the system from it. We can accommodate it, move it, or ignore it (at risk of peril, and hope we get/stay lucky).

If we can take pressure off the need to always lead on invention, we can perhaps be more innovative. Applying others' inventions to create greater value by carefully designing the meaning, and all it implies, of the system. Take Apple as a case in point.

System meaning is the source of design themes. Design themes give coherence, one of the legs, so to speak, of structural integrity. And structural integrity is intimately interwoven with the broader notion of design integrity--not simply a component we can split off and deal with separately, without concern for the interaction between structural integrity and design integrity.

So we get back to the mind-hand interworking, the mind creating meaning the hand shapes, putting something into the world that is interpreted and interacted with and imbued with meaning, priming the next round of evolution of meaning-making and meaning-building.


1/13/11 Tread Softly on Dreams

We had a snow day and the kids spent hours tunneling a pile of snow, imaginatively and by dint of laborious work building a snow fort. When they came inside to warm up, they saw, to their horror, a neighbor's child and his friend jumping forcefully and vigorously on the roof of their fort.

Some people take pleasure in tearing down dreams. Way too few take pleasure in seeing them and lending their unadulterated enthusiasm. People who reach and strive are self-critical. So tread softly on their dreams.

If I have concerns, I try to raise them first to myself taking the other person's (or team's) point of view. If I still think I have something to offer to help build the dream but with more resilience thanks to my intervention, I look for that circumspect path that communicates, through my earnestness and care, my sense of appreciation and value for the dream and the dreamer. It is not shying from "putting the source of the bad smell on the table to be dealt with unequivocally" but rather it is about looking for a way for the team to find the smell themselves, so their resources and energy can be effectively applied. They think they did it all themselves. But what of that? I'm not trying to build a kingdom!

1/13/11 Decisions, Concerns ...(re-)Defining Software Architecture

Many definitions of software architecture and system architecture, for that matter, focus on the structure of the system:

"The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both."

-- Clements, Paul; Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford (2010). Documenting Software Architectures: Views and Beyond, Second Edition

"Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."

-- ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems

Other characterizations focus on architecture as a set of decisions:

"Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be canceled."

-- Eoin Woods, 2010

"All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." -- Grady Booch, blog post, March 2, 2006

Yes, these decisions shape--give form to--the system. But they also shape--set direction; constrain; bring integrity, consistency and unifying aesthetic to--the system. And, yes, the structure of the system encompasses decisions, so there is at least an overlap between these definitions, but the emphasis is shaded differently. And both are important. How important, we see when we "unpack" or tease out the definitions or characterizations.

Historical note: we also characterized architecture in terms of a decision set in our "Less is More" paper (in IEEE's IT Pro, Sept/Oct 2002). We possibly weren't the first. But we were early to the game of characterizing "significant" and hence part of the architecture (decision set).

I jotted the points in the image above, attempting to express the essence of our view of architecture to an architect; there are little tremors of discontent around the nature of architecture in the wake of agile and fully empowered self-organizing teams...  Let us focus on complex systems where we need to pay design attention to achieving desired system capabilities with intended properties. This is an important idea that often gets lost--it is one of those "so obvious it gets hidden in plain sight" notions. We design to bring intentionality to bear. [It's that Herbert Simon insight: "Everyone designs who devises courses of action aimed at changing existing situations into preferred ones."] In particular, to meet system goals, which are largely expressed in terms of functions or desired services. Or expressed as capabilities or features, which I think of in terms of "what" (functions) and "how well" (properties). Designed, what is more, in the context of constraints and direct and indirect forces, drivers, points of tension; that is, designed for structural integrity and resilience in the face of dynamic load and the demands of market and system evolution. Designed, therefore, to achieve outward or user-facing and operations-facing qualities (of the system in use/operation) as well as code qualities that determine it's sustainability through adaptation and evolution.

Strategically Significant

Ok, so if architecture is a set of decisions, but not all decisions, which ones belong in the architecture? Those that have the highest cost of change clearly. Clearly? If a decision would cost a lot of resources and time [and operational downtime or deferral of value (Kris Meukens) and "emotions and politics" (Doug Newdick)] to change or revert and rework, it is strategic. Likewise, if a decision meaningfully reduces the cost of making changes, enabling our business to be more fleet, adapting and extending its services or product set as the market shifts, it is strategic. It impacts our competitiveness. Which sheds light on the bigger distinguishing characteristic of architectural decisions--they are strategic. They have high impact. They are crucial to competitiveness, especially when we take a longer view. Make or break. Game shapers and game changers.  In my blog, back in 2006, I expressed it this way:

The architect of early generations of HP OpenView said “Architecture is the translation of business strategy into technical strategy.” This definition focuses on the strategic nature of architecture. What is significant, in this view, is driven by what is strategic, and what is strategic determines how we will compete. How we will differentiate dictates the big things we must get right, what hard problems we will tackle, where we will innovate, and where we must be ahead of competition. And it allows us to accept good-enough along those dimensions where we are not trying to create competitive advantage.

--  moi, What is Software Architecture?, Trace In The Sand blog, 7 May 2006

What is architecturally significant, then, is decided by the architect (or those wearing an "architect hat"), taking into account business strategy (at the applicable level of scope); the user, business and development context and the desires, demands, constraints and forces therein; complexity, challenge and risk; and the cost of change. This is not to suggest the architect is all-powerful, nor that this is done all upfront. Rather, deciding that something is architecturally significant means it is one more thing the architect (or architecture team) is going to need advocate and explain and defend and influence and coach and tend...nurturing and evolving the design in the context of organization needs, forces, personalities and more. [See minimalist architecture.] [1/31/13: Strategy, in our view, is not all feed-forward and top-down, but Fractal and Emergent; that is, there is a dynamic dance of intentionality and emergence in both strategy and architecture.]

You could say that the cost of change includes the cost of being wrong, and this could just as well be wrong about the market (or the feature set we choose to address the market) as wrong, for example, about a choice of technology that is threaded inextricably through our system and which may prove to be a bad bet. So we could bend our interpretation to fit Grady's characterization but I think that it is well worth the attention shift to go the other way. To highlight the strategic nature of architecture decisions, and subsume high cost of change within strategic. Or to tease these out and include strategic, high cost of change and, for that matter, high complexity (or challenge, uncertainty and risk).

Designing The Defining Structure

But... that's not all. Bear with me for I feel a bit uneasy about leaving things at "architecture == set of significant decisions" and I'm trying to feel my way here. Consider this, for example, from wikipedia:

"architecture defines the structure and/or behavior of a building or any other kind of system that is to be or has been constructed."

Defining the structure means making choices -- we're going to put this here and that there, carve things up like so, connect things like so. We're going to make it resilient like so. Scalable like so. Choices. Decisions. We're identifying demands on the system, the challenges, issues or forces we must contend with, and defining the structure (comprised of structures) and behaviors (changes in state, interactions among structures, control, etc.) and these impact one another. So we have to make tradeoffs. The structure will convey and conscribe behavior, so it behooves us to reason about the behavior (or "how it works") and the implications for the structure (and vice versa), though our structures may (will!) convey and enable more behaviors than we define (explicitly in our design). Likewise, the structures and their interactions give rise to the properties of the system, and it behooves us to bring experience and analysis to bear on the design to get more the properties we want. We're designing the mechanisms to address demands on the system, figuring out how to deal with the challenges of these demands and forces like entropy and uncertainties such as those raised by possible failures and changes in the demand landscape -- all within constaints such as cost and important release milestones**. And we're assessing how various approaches contend more or less well with different sets of challenge and uncertainty, altering and amending and redesigning the system structure in that light.

So, yeah, I think architecturally significant decisions are central and shape and are shaped by the structure, but the defining structure is a definitive part of architecture--that is, part of the very identity of architecture. Now this structure, for complex systems, is composed of structures--the major elements of the system and their interrelationships and key mechanisms. Mechanisms, again, are composed of elements that collaborate to some end, to fulfill some purpose like provide a capability or address (an aspect of) a cross-cutting concern. We may decide to use an existing mechanism design, generally expressed as a pattern in our field, or we may articulate our own design in the pattern form, so that the design is used consistently wherever it is applied, bringing conceptual and structural integrity (assuming it is a good and proven design) to the system.

Now I say this because we need to keep in sight our defining purpose. We're giving shape or form to the system--paying attention to the macro structures and interrelationships that contribute to the structural integrity and sustainability of the system, as well as any more granular structures that contribute to design integrity, providing for consistent approaches or to address a cross-cutting concern. But the form should deliver and serve the system function(s) or capabilities, and it should be sustainable (so evolvable and, as pertinent, scalable, and so forth).

Hence we are, for example, assigning responsibilities to architectural elements (conceptually, components or chunks of the system). Yes, this is a decision. But we aren't going to fill out a decision template for each responsibility we assign. Well, I wouldn't advocate it! That'd be unbearably onerous to do and to consume! So we are going to chunk up and describe and rationalize why we cluster the responsibilities the way we're choosing to. And so each design element is a whole set of (more granular) decisions. And we document our design, provide a narrative that tells the story of the choices we made and why they make sense. But the key is the design, drawn as a (set of) model(s) (visual, symbolic, textual, or a combination), and explained using words and possibly (probably) more models (or diagrams or sketches or code snips or prototypes).

This design is just one of many possible designs each of which will address some conjoint set of requirements and forces differently. So a key activity in design is reasoning about the relative merits of various options that open and close at different points in this multi-dimensional choice space. There are so many options we aren't even going to see all of them, but we try to keep a trace of the thinking and the doors we close (options we decide against) and avenues we keep open (making assertions about what we expect this means). So all this is not a matter of decision by decision documenting on a template. There are just too many. But we try to keep the narrative, the story of our reasoning accurate and true to our choices and reasoning. This will be invaluable in explaining and defending and evolving the design. But there will also be choices that are so subtle we didn't even know we were making them. Life. We do what we can, and count our blessings for blink intuition. We try to surface the reasoning behind the designs to communicate it, but we're a step ahead if we have explicit designs! Every now and then we'll pull out a decision as a big shaping decision worth documenting in a way that we can pull it out and it is a thing, a decision. And other decisions we will subsume into a view and describe the general reasoning behind the choices and highlight the important defining characteristics of the design and the rationale for those and implications and such. The context for all the decisions on that view is shared; that saves us (and our readers) work. Within a design element (like a component) there is again shared context including shared rationale. Etc. So, what I'm trying to say is that we have some of each. We have decisions we document formally. And we have designs that are inherently many choices or decisions, but we document them not by teasing each one out and trying to give it a systematic full decision template treatment, but rather in a more aggregate form, in families of decisions, if you like, as pertinent to the design or element of the design. For example, we document each component on the conceptual architecture view, listing its responsibilities and the principles and overall rationale for this clustering, highlighting what is important to draw out.

So I don't so much care about the language we choose to use here, but I do very much care about the behavior it causes us to adopt. If we say decision and decision means document with a template that is a slippery slope to a lot of documentation. Well-meaning... but as you can see from my journal, a well-meant pile of words is almost as useless as no words. ;-)

Inherently we're "giving shape to" the system. Principles and values and other expressions of culture are part of what we use to do this "shaping," this influencing of the form and the expression, the aesthetics and the properties of the system. Giving "shape" may not (though for agility/evolvability/adaptability generally does) mean "modular" but does mean some conceptual structural elements are being designed--whether we think of behavior in the foreground with structure in the background (providing the "nouns" if you like) or vice versa. They may be highly distributed like role-related responsibilities associated with aspects or cross-cutting concerns. Or consolidated into a modular element. And where decisions, like which technologies we're going to use, "give shape" to the system in profound ways (making them costly to change, but also influencing the very nature of the thing--its significant properties) these are architectural too. Rats, I just stumbled on another dimension to the way we characterize architecture, didn't I? ;-)  [I write to learn, to see... and risk being foolish.  We add detail ("complify"?) to find the simple, essential structure ("simplicate"?). The thing about how we characterize architecture, even if it seems an over-raked turf, is that it orients us -- it points the direction, sets expectations, even impacts how we feel. If you don't agree with the last, how does that make you feel? Oh, now you get my point. :-)]

Is/Is Not Architecture

To clarify what something is, it is often useful to consider what it is not. Architecture is often called "high level design" distinguishing it from "detailed design." And architecture is distinguished from "requirements," separating "the what" (what capabilities, or functions and properties, the system will offer) from "the how" (how the capabilities will be built). Rather than "high level design" we prefer to think about architecture as decisions made from the system perspective with system outcomes in mind, and rather than thinking of requirements as some sort of "capture" activity we think of it as part of the design activity that relates to identifying desired system capabilities while architecture deals with designing the structures (elements and relationships) and mechanisms to deliver those capabilities (including system properties, like those that relate to structural integrity and evolvability).

Decisions Made from the System Perspective

We help make "architecturally significant" more clear using Dana's "umbrella diagrams" (visualizing decision scopes; e.g., system, subsystem or service, and component scopes; or product family, products, features, elements; etc.). different scopesArchitecture decisions are those that need to be made from the system perspective taking into account their impact on system outcomes. They are decisions that need to be made across the boundaries within the system, and between the system and the environment (hence the "umbrella" or arc across scopes). They have extensive impact, and are of great consequence to system success and viability, integrity, sustainability. For complex systems (where architecture really becomes important), architectural decisions need to be the responsibility of someone with system purview; if made by someone with limited visibility across the system (i.e., they have local decision scope/responsibility, perspective into and experience with a piece of the system) they could adversely impact desired outcomes in some crucial way, because they wouldn't have the perspective, or the local interests of the piece of the system they're vested in would tend to bias their decision in a way that doesn't best serve the overall good (impacting the emergent properties of the system, or impacting other pieces of the system adversely). And they require expertise in system and mechanism design, experience in the domain, and more. ***

Yes, this is cleaving the space in the way of The Master Butcher in the Taoist story, but really, ask yourself, is there any other way? There is no recipe, no universal rules, for what is architecturally significant. Context, experience, and more all factor. There are places where things seem to just fall into their natural structures and others where we have to slow down and really pay attention, to find the interstices. The larger organizing structures are more clearly architectural--at a minimum, they bear high cost of change. Mechanisms whose impact permeates the system (from those embedded in a technology choice like an ESB, to those codified in patterns which also may be inherent in the framework of choice, like MVC in ASP .NET, to mechanisms we design to address a cross-cutting concern, and more) are likewise architectural (bear high cost of change, strongly shape the system lending consistency and integrity--assuming they're well designed and proven). 

[Caveat/aside on implications for the architect: All this is not to say that the architect does all this shaping on her or his own, nor even that she or he makes every architecturally significant decision. It does mean that the architect leads and is ultimately responsible for the system design (as intended and as realized) and the architecturally significant decisions. Thus, for example, when a decision or practice will or is subverting desired system outcomes, the architect gets to decide (as fits the case, in collaboration with the team and/or management or with the trust and mandate of the management team), what to do. At any rate, getting more clear on what architecture is, helps clarify, but does not dictate who makes the decisions, and who, for example, shapes the development culture, with its values, mores and practices--though it is worth recognizing that the culture plays a significant role in shaping the system and so is a point of architectural leverage. The more you place value on "servant leadership" and empowered teams, for example, the more you will want to avoid casting the architect as one who mandates unilaterally. That said, while we rely on collaboration in the development teams to define the elements and interfaces, we rely on the leadership and authority vested in the architect, and goodwill and good followership of the development teams, to ensure structural and conceptual integrity of the system, and more broadly, design excellence. In other words, in the fray of getting things done, the architect is chartered with looking out for structural and design integrity, and while everyone acts with good intentions, what they are paying attention to tends to be local to an area of the system, which may be a feature, service, component, element, whatever. The point is that it is scoped more narrowly than the system, and decisions made at that scope will tend to bias to optimizing at that scope just because that is where the attention is at that point. The architect role is to provide counterbalance, and continuously bring the system perspective to the table when system outcomes are threatened by local decisions. These include "local" in time -- that is decisions that optimize for now, but build debt in defering decisions and work that will have high "interest" or rework/revert/recover costs later.]

Where It Gets (Still More) Murky

Ah... Any characterization of architecture has fuzzy edges for me... Is the resultant of not making explicit architectural decisions still architecture, or should intentionality be implicated in the definition? For example, if we eschew explicit architecture, slipping and sliding into a big ball of mud without intentional, ongoing, redressment of entropy, we enter the zone of high cost of change. It has huge architectural consequence, but is big ball of mud an architectural style or anarchy and chaos?  Are shanty towns allowed to develop as a "pressure release valve" so that the need for no-cost housing for the utterly poor is given an outlet and these people are kept out of well-to-do neighborhoods? If so, is this an intentional blind-eye that "serves" the bigger system? [Of course, those are not my values or preferences!] Are "shanty town" systems similar in some way? Building is a way of giving shape to a system, raising it from nothing more than an idea to something that exists in the world (though perhaps pretty much invisible within a larger system). But if we let this building produce an unstructured mess that does nothing to serve the quality of life of people who interact intimately with the system, do we think we have given shape to the system or abdicated our responsibility to give intentional shape that delivers sustainable value? Abdicated, that is, our responsibility to make things better through design, through intentional application of our wherewithal to making things better? 

Architecting Across "Requirements" and Architecture

Generally "requirements" (identifying the desired the functions and properties of the system) don't pre-exist just needing to be written down, but instead are part of the design space. Architecture is about form and function, and how we shape the form to achieve function with system properties that include a span from those that are more aesthetic to those that have to do with resilience and sustainability.  Since the design space is large, we have to be strategic about our choices. Strategic in how we approach making choices (which we consider, who does it, when, etc.), and strategic in the making of the decisions (considering business interests, and the whole envelope of concerns of customers/users, developers and other internal stakeholders, and more). The design space includes choices we make about function and about form, and these interact, and if we separate them, in some ways we reduce the design space. That makes things apparently simpler (allowing us to carve up job responsibilities and stage the design process), but it may raise the cost or lower the value of the system--may, but how would we know, since we have artificially and prematurely cleaved the space without sense of context and the opportunities and challenges it raises?*

Architecture, Then

Architecture is about system design. So architecture is about the system in its context, and about parts and their interactions and collaborations giving rise not just to system capabilities but system properties. This we call synergy. System properties are emergent from the elements and their interactions. This is not to say they are always and entirely accidental. We can, applying experience (our own and consolidated in the growing body of knowledge of our field--for example, in the form of patterns and even tools and codified in our development environment/infrastructure) and reasoning, bring intent, or goal-directed purposive design, to bear to ensure the system has more the properties we desire and less the properties we don't. We're always pushing the envelope on system designs (else we should not be designing, but rather choosing someone else's system) so there'll be surprises, but we don't make the world better without acting intentionally and then entering a cycle of reflect (how well did we do, did we get what we expected, what did we learn, what should we try next) and improve.

Well, if architecture wasn't tricky enough, how about the word initiate when used as a noun? and Collins have opposite definitions!

Tricksy stuff!

Tricksy. Hobbit. Oh, did you see today's xkcd? I visited with Dana and kids during their reading of the Lord of the Rings and it contains some great leadership and life material.

See also: post on 5/22/11 Architecturally significant

7/26/12: * Just in case that isn't entirely clear, what I said there is a criticism of waterfall! It is noting that we need to design across the design space of system capabilities and user experience and the internal structure of the system iteratively.

More helpful references:

1/31/13: ** On the matter of release milestones: software is woven into all manner of systems, some of which have different release constraints than others. Continuous deployment to a pace maker is a different matter than continuous deployment to the heart of Facebook. We want to move more towards continuously deployable, and that too becomes a design force. Thhe design force or constraint being my point. So hopefully no-one gets confused if I focus here on what architecture is, and don't talk about all useful or even "imperative!" practices in the entire software lifecycle from initial conception to decommissioning. Smile!

Complify and simplicate are terms used by Dan North and I first encountered them through one of his talks, but he ascribes them to someone and I didn't catch who. If you know, please tell me the source.

1/31/13: On very useful and much appreciated feedback from Kevlin Henney, I added a clarification: strategy, like architecture, is dynamic -- that is, both intentional and emergent (see The Art of Change: Fractal and Emergent, 2010). This notion is so baked into my thinking about strategy and architecture that I can forget to point it out. The point I was trying to make is that the architect is translating from business terms into technical, clarifying the design envelope and how the system will support differentiating as well as essential system capabilities, etc. Strategy is about setting direction, and shaping direction, and we want our technical direction setting-shaping to fit and enable the business direction.

I hope that it is clear that this was a trace on what architecture is, not how and when the decisions are made. Separation of concerns, and all that. :-)

*** When the team and code base is small, the situation is quite different from when it is large, and complexified by lots of different organizational groups and organizational and cognitive distance, charter differences, etc. In the small, architecture can be treated more organically than in the large, where we need more in the formal organizational structures, communication and process "scaffolding" to support structural integrity and design effectiveness, even excellence.

11/16/13: See also:


1/15/11 Them Tricksy Words!

Words! I was once earnestly and with the best of intentions chastised for using the word "component" talking about architectural structures. But the word simply means "an element of something larger," and that something larger sets the context for interpretation (for example, in conceptual architecture we obviously don't mean binaries). Well, I don't want to raise artificial barriers to the way I talk about architecture, so I have tried to shift my language more to "architectural element" or "element" even though I think component is a perfectly good word and non-software architects get to use it in ways that make sense... using it to mean such diverse things as a "component of my vision" (which translate, often, to a set of features, if you like) to a major assembly (which might be productized, like components of a hi-fi), to a discrete part of the system. Our "assemblies" may be designed around a feature, like a "software cell," or an internal service that used within composed collaborations to deliver features. I know it can get contorted for example in the SOA context, to say a service is a component of a system, and a service is comprised of components. I do realize that we tend to relate "component" to parts that collaborate to produce features, rather than parts that are fairly fledged features. I didn't say full-fledged, because they still depend on other parts, for example for shared context, and aren't stand-alone systems (in the Rechtin sense of system). But in general, talking about architecture in general contexts, requiring a conscribed sense of the word component seems like wanting hard lines to be drawn where hard lines don't exist and aren't even necessarily helpful. Can't we accommodate both the innocent simplicity of "element of something larger" and the more particular meaning, for example, that UML ascribes?

We want ground under our feet, but hearty rich soil, not sand sifted clean of all its texture and nuance. That sifted sand has its uses. We can build with it. But things grow in rich soil. We're talking about a space that spans great buzzing confusion all the way to professionally designed and soundly engineered systems. So we need to accommodate organic and mechanistic. Perhaps our language should too. If we are too pedantically tied to one interpretation, we close off other options. I try to remember to use element to message that openness. For it is an openness to interpretation, when we are exploring how to define our systems, that orients us to new possibility. If I step on definitions people hold "sacred" they close at least that part of their mind to me. So I have to be careful, but at the same time an open attitude and goodwill is important on both sides of a conversation when we are exploring what might be.

1/31/11 Interactions

1/17/11 For Fewer Words

See Elements of Architecture

1/20/11 Navel Gazing

It had occurred to me that my post (above) on architecture definitions is an exercise in navel gazing, and that notion jumped into full sight when I chanced on and read this:

“How many sociologists does it take to change a light bulb?”

A: The very suggestion of a light bulb is a Western hegemonic account requiring emic validation. That is, the light bulb represents a recursive and socially embedded focal artefact, which cannot be decontextualized. In fact, its very “existence” points out the localness and relativity of boundary objects. The light bulb hence is nothing more than a cultural rhetorical device, scarcely agnostic, and thus surely constructed. The light bulb then only exists in text and word, and receives its ‘realness’ in text and word, only.

-- Paucis Verbis blog

Paucis Verbis indeed... Well, with so challenging a title as that, I had to look at something else on the blog to size it up. First stop: Think before you buy -- how's that image set for illustrating the power of the visual? (Be sure to look all the way to the end!) Pictures say a lot, don't they?

1/15/11 We Build Ourselves to Build our World

I have, in various contexts and over the years, expressed my sense that we build our self, and that our own self is the most important work of [spirituality,] art and engineering, of imagination and of practicality, that we build in our lifetime, for it is of that work that we are enabled to build works in the world (whether process or product, whether through influence or in constructed stuff, etc.). And we're discovering that this work we do changes the very structure of our brain [see the inset about cabbies; I'd like to see that study done on software developers ;-), I mean, think about it--the mental model we hold of complex software systems has to be every bit as complex as a mental model of London; wouldn't it be interesting to see ]. It changes our nature in tangible ways. What we do with our bodies and the very thoughts we have, shapes what we are capable of, but also builds what we are. A being. Full of becoming.

[Thanks for the pointer to the article Daniel.]

1/15/11 A Visual Moment

These two versions--Snow PatrolVEVO and Grey's Anatomy Version--of Chasing Cars illustrate the impact of the visual -- not just using the visual channel, but using the references, the cues, whole stories that get compressed into visual moments. I haven't seen the TV show, but that's not required for the moments are quintessential and iconic. The jaded might say stereotyped or hackneyed, but we don't have to see through those eyes, now do we? My introductions to a beat off mainstream are via Sara who gets it through Jazz Dance class, but Chasing Cars came via Sara's harp recital--one of the older girls in the precollege harp program played (the harp) and sang Chasing Cars with a friend (who accompanied her on guitar). It made me tear. I'm not usually that soppy, but "before we are too old" sung by teenagers (as though they really meant it) to a middle-aged audience of parents was so poignant! My kids are at that point where they hold the last days of childhood dear. As for us, we're not too old to play pretend, but other things inevitably pass. At all of these life transitions, if we're paying attention and notice the passing beyond, it is at least poignant!

Growing Old

In some summers there is so much fruit,

the peasants decide not to reap any more.

Not having reaped you, oh my days,

my nights, have I let the slow flames

of your lovely produce fall into ashes?

My nights, my days, you have borne so much!

All your branches have retained the gesture

of that long labor you are rising from:

my days, my nights. Oh my rustic friends!

I look for what was so good for you.

Oh my lovely, half-dead trees,

could some equal sweetness still

stroke your leaves, open your calyx?

Ah, no more fruit! But one last time

bloom in fruitless blossoming

without planning, without reckoning,

as useless as the powers of millenia.

-- Rainer Maria Rilke, Growing Old, translated by A. Poulin

Rilke died when he'd just turned 51. Isn't that a rallying call? To reap our days and reap our nights! Before we are too old and bear no more fruit.

[ee cummings poem in time of daffodils(who know is a wonderful poem about life's seasons. ♫This choral composition sung here by chanticleer is lovely. Naturally I think that we can take this recursively, with many iterations through the seasons during the "time of lilac" and "time of rose" of our lives.]

1/15/11 A Musical Moment

We thoroughly enjoyed Tim Reed's CD release concert tonight, with music from Euphoric Owls (recently released) and songs from Carry Me (soon to be released). It was, in a word, AWESOME. 

I laughed, I cried. In the music, lost and found my self. Really amazing, beautiful ... words fail me. But... as you well know, not for long. ;-) Ok, I've recovered enough to share a few. We all loved it. Tim reached across generations and made everyone feel. Quiet and awed. Smiling tender and smiling warm. Touched and blessed. What talent he has collected around him; they complement him well. Ariel was breathtaking!

I notice people who just laugh easily because they are, frankly, rare. It is not that they treat life superficially or that life has been easy on them, but they are fun's ready companion and laughter spills easily from them. They make us feel good. In this moment, I can think of only three--of whom Dana and Tim are two.  

1/16/11 An Olympian Moment

Jessica Hagy's Little Something is brilliant!! Truly inspired!

Life's contrasts. The opposites that are paradoxically held in one form- and state-shifting being (if but a conceptual one).

1/17/11 In Honor of Martin Luther King

Martin Luther King led us to a step-change in our social evolution. As we celebrate what he accomplished, let's also remember that we haven't erased our habit of placing people in diminishing boxes. We still do this by race and gender and more. But the habit of scorn, of belittling people, of seeing them as less than ourselves along lines we impose upon them, shapes and shrinks our worlds in so many ways. So on MLK Day, let's break some boxes!

Sara wrote this poem when she was 7 (if you were reading this journal back then, you may remember it):

A Lullaby You can't Hear

A lullaby
That soothes your heart
Yet you can't hear it
You fall to the rhythm which does not have words or sound
The kind of lullaby that God whistles
A kind that is called peace.

When we listen heart-mind open, as this child did, as a young child can, our heart-mind knows that it doesn't need others to tell us what is good. We fall to the rhythm.

Not "you fall into rhythm" -- not you fall into line. We fall to the rhythm. The surprise cast of words. We fall to. We yield to. 

Peace is without lines. Without aggrandizement. Of self. Of social group. Of gender. Of age group. Of color. Of belief system. All the ways we elevate without compassion or heed to what is just.

Let's do something about boxes! Let's rid ourselves of the shams we paste on people we've boxed--those tidy labels of diminished expectation.

Sara also wrote this playful piece in the same timeframe (when she was 7):

Poems for children


Work is for

Finally getting it



                         The night is for

                         Making sure you don't fall asleep

                         In school


                                                                           Shops are for

                                                                           Getting more stuff

                                                                           For them           


Dreams are for

Keeping you entertained during

The night


                         Compasses are for

                         Learning how to

                         Use them

She called it "Poems for Children" but we adults have much to learn from it, do we not? Compasses (including moral compasses and 97 Things) are for learning how to use them! (Shops are in a loop of selling to do more buying to do more selling. Work is for -- finally getting it! Correct. Oh, I finally get it. The child, 7, got iteration. Persistence. Understanding. I didn't edit her words to say "right" because "correct" is more correct. It is what we make children strive to accomplish, is it not? And that burns in a pattern of trying to get things correct. How partial that is!)

I do hope the child returns to listening to her poetic muses, the kind of lullaby God whistles, and the face in the window:

A face in the window

is calling your name

Someone calling from the past,

pale from being so old,

only living in your memories

staring from far back in your mind.

A face. Yours? Your father's? The sister of your childhood self? Each of us has that someone who calls us to be more who we wanted to be when we were innocent-naive, unbent by the hammering and silting of time. And that is only one way of reading Sara's poem!!

Did the child mean the poems the ways I read them? Emergence, my dear--(in reading here) so dear--friend. Poems, like (other) systems, are great for the emergence they allow as well as the intent with which they were mind-fully crafted. A child who wrote such poems knows more than we might think, but also prompts us to think more.

Never underestimate a child. Nor a woman. Nor a man. Nor a person of any color (those of us who are so-called white people suffer life's formative lessons too). Nor a geek (we geeks span contradictions too). Nor a Christian. Nor a Muslim. Nor an atheist. Nor the so-called hearing (we too have to learn to listen with feeling). The list is long, and if I try to make it more complete, those I leave out are the more wronged. So simply accept my good intentions and make your own list of individuals and groups we wrong by expecting less of them because we precast them with expectations we expect them to live down to.

Ok, back to creating stuff that is useful! See ya!

1/17/11 TGIM!

But. Before I go. Let me just say: XKCD has changed the world hasn't it? My waking thought this morning was: TGIM -- a new XKCD! I searched for TGIM on the xkcd forum thinking that has to be clichéd yet the only entry is from today! How weird is that?

Not so weird at all. Randall's "family illness" (and Fridays' awesome strip) reminds us to count our blessings, and xkcd is one of our blessings! Top ranking, if you ask me!

You didn't. So. I never let a little thing like not being asked stop me! Five years of unasked-for journaling. Almost. That's a lot of evidence! Ok, ok, I'm going. I've got work to do. You too!

1/1711 Technology Driven Resurgence

This is an exciting collection of examples of innovation in business models inherently wed to technology (and relationship platforms, per my Art of Change paper): 10 Business Model Innovations that Rocked 2010

This is an exciting example of competing on analytics (another avenue highlighted in the Art of Change paper ;-) :  Big Data, Analytics and the Path From Insights to Value by Steve LaValle, Eric Lesser, Rebecca Shockley, Michael S. Hopkins and Nina Kruschwitz, MIT Sloan Management Review, December 21, 2010

And with respect to BI, the "ability to speed the time to insight amid vast amounts of data" puts visualization at the top of the list of the Five big themes for BI in 2011, by Cindi Howson , InformationWeek, January 17, 2011.

More news to boost confidence in a "tech-led economic resurgence":

1/17/11 Instrument and Visualize

I liked this blog post titled Learning from Others (teaching us to learn from our own data) by Dan Pritchett on logging production metrics and visualizing this telemetry. I waited so long for Dan to get back to blogging, that I didn't notice he had---until I saw that Martin Fowler had blogrolled him on his redesigned and updated bliki site (it's looking good)!

1/18/11 Art in Engineering

I think Jim "Cope" Coplien is onto something, though I would probably shade things differently... and that is part of the point!

Anyway, this is interesting:

"But how could you get kids who had historically struggled at math — who had failed prior courses in earlier years — to improve enough that they could pass Algebra I? What did the data advise about that?

The answer was astonishing. What turned out to be the best predictor of Algebra I success for students who had failed previous math courses? Success at eighth-grade creative writing."

-- Big Data, Analytics and the Path From Insights to Value by Steve LaValle, Eric Lesser, Rebecca Shockley, Michael S. Hopkins and Nina Kruschwitz, MIT Sloan Management Review, December 21, 2010

Why interesting? Problem solving is highly conceptual. Einstein and Feynman were great because they understood, instinctively, the connection between the imagination, the ability to "see" with our mind's eye new ways to frame up problems, to cast them not just afresh but from different angles, to shape and see them and then to solve them. So a key to designing more complex systems is in good part to develop more interesting, more varied, more limber ways of repositioning and taking different perspectives with our mind's eye. No one is discounting the importance of deep technical and domain knowledge, but keeping the part of the brain that is good at conceptualizing healthily active is important too. And this journal is a good workout. ;-)

Software design--which is just as integral to writing code as it is to architectural design--is highly conceptual. As for architecting, varied art forms come to bear.  Storytelling and meaning making among them. Notice how we, and the community, incline to Grady Booch's awesome paper (improved, even, with his reading) on systems and failure. This is every bit system engineering and analysis, yet delivered in a way we readily associate with art and beauty. Yeah, he's good--like great! But he's good because art and reading have been part of his life, too. Too.  

Leonardo da Vinci was a prolific inventor in good part because he was an artist. He studied mechanisms actively by drawing them. I read that he copied the sketchbooks of other artist-inventor-designers, as was a common practice in his day (you know, that was before Google and Facebook and such). That little nugget of history contains so many lessons. Drawing. Mechanisms. Copying/studying precedent. Community of practice. Connections. Innovations. Art and engineering.

We might say engineering is improved by art, by the keen aesthetic sense yes, but also by what we learn about making meaning. So, some will dismiss the notion that art has much place in engineering, while those that embrace it, will have the kind of advantage Steve Jobs stumbled on, when he found himself drawn to calligraphy and so to the importance of design--and design not just of the skin or how it looks, but how it works. One might argue that we cover this base by including a design class (in the user experience/skin sense) in the software engineering curriculum, but I intuit that any way that we expand and deepen our selves will spill into better designs. We'll develop our own distinctive aesthetic sense which will lend a stamp of uniqueness demarking it from run-of-the-pack, and we'll develop empathy and imagination, we'll develop other reference-points from which to draw analogies, etc.

"Google includes a wide range of personalities, and our designs have personality, too. Text and design elements are friendly, quirky, and smart – and not boring, close-minded, or arrogant." -- Google User Experience

Some related thoughts:

More Feynman:

 Any questions?

[Here's an interesting/provocative perspective on education and parenting... Our world will need a great many people who are very singular experts. And a great many people who can go deep, yet also make connections, ask new questions, work across boundaries, address complexity. ... This cartoon reaction is worth a scan.]

1/18/11 Visual Complexity

  • Animal hands!
  • Leaf visualization -- visualizing and quantifying structure. What people outside software are doing with software to visualize the structure of systems is inspiring, isn't it?
  • Beautiful Visualization, Julie Steele; Noah Iliinsky, O'Reilly Media, Inc., 2010

1/19/11 Design by Analogy

Here's a neat example of looking to analogy to find a solution: Fruit Fly Nervous System Provides New Solution To Fundamental Computer Network Problem. Remember, analogies are not identities, so we don't look for a one-to-one mapping and throw our hands up in despair at the differences. We look for ways that the solution (or concept) in another space informs and enables a solution in ours.

With a minimum of communication and without advance knowledge of how they are connected with each other, the cells in the fly's developing nervous system manage to organize themselves so that a small number of cells serve as leaders that provide direct connections with every other nerve cell.

Analogical reasoning is immensely powerful! Yes, decomposition into smaller problems we know how to tackle is powerful too. We need a bunch of tools in our toolkit, so we don't just hammer something out that works okay-ish... for today... but rather deftly craft sustainable solutions. Looking for proven solutions to analogous problems so we can translate that solution to our problem is a strategy. A very useful one.

1/19/11 Self-Organizing Development

Here is quite possibly the most exciting thing I'll read all week, and it comes via Sumit Pal on the Bredemeyer Software Architecture Workshop Alumni LinkedIn group:

The post about the culture at PayPal is interesting too.

1/19/11 Architectural Form versus Structural Form

I thought this distinction from the building architecture space is interesting:

Architectural form is

dictated by architectural purposes, such as the practicalities of spatial organization and control of the flow of occupants. Architectural form is also concerned with the sense of space a structure creates, its symbolism and its relationship to its setting”3.

Certainly architectural form can lean toward sculptural form as in the case where architectural “elements are exaggerated or when forms reflect a nonefficient use of material just for the sake of emotional impact”4. But architectural form is always at least somewhat functional, it is always three dimensional and typically it is client driven. It must satisfy the needs of the client and the occupants, yet it also must satisfy artistic and creative goals of the architect. Finally, it needs to be safe, since it ultimately will be used by people.

Structural form is

dictated by structural needs, primarily to support gravity and lateral loads, and usually also the need to provide a building envelope for shelter against the elements. Carefully designed structural form can exhibit the stark beauty of controlled strength, even to the point of excitement. Structure can define the visual impact of a building, as in the case of large exposed columns which give the appearance of strength and solidity, or the case of tall slender columns which can create an elegant loggia effect.3.

Structural form is mathematically based, it seeks the greatest efficiency, economy and elegance that the designer can create. It is not random, it is not generated by trial and error, it is not subject to changes in taste or fashion, it is not symbolic of some anthropomorphic idea.

3. Saliklis, E.P, Bauer, M. and Billington, E.S. (2006) “Simplicity, Scale and Surprise: Evaluating Structural Form”, Accepted and scheduled for publication in the American Society of Civil Engineering’s Journal of Architectural Engineering.

-- Edmond Saliklis, AC 2007-313: EVALUATING STRUCTURAL FORM: IS IT SCULPTURE, ARCHITECTURE OR STRUCTURE? California Polytechnic State University

For some, software architecture is more like structural design and for others software architecture encompasses both functional or purposive form and structural design. Where one lands should depend on the nature of the problem in its context, not on one's own personal preference for taking on only the more technically challenging aspects of the design (like how to scale). Actually, scalability is very much about partitioning, which gets us right back to the interaction between  responsibility factoring and distribution boundaries (or conceptual and execution architecture views). Which is why I don't advocate cleaving the architect role into "functional architects" and "technical architects." I do see a great need especially in large IT shops, for creating a formal structural specialist role (like integration, virtualization and security specialists) who are resources to architects and their development teams. This is just a recognition of the deep specialist expertise that needs to be developed and leveraged across systems that have stringent demands in key areas.

1/20/11 Wordle Fish!

Given the cool Google search image today, I wanted to see if Jonathan Feinberg (Wordle) had followed my "suggestion" and created the ability to fill a shape with the words in Wordle... Well, its still a word splat, but I liked that when I tossed in January's words (so far), the Wordle generated looks like a fish! How appropriate!

"Just think"! "Make visual"! "Design one architecture"! "Code see"!

"Words need time"...



Eh... Not so fast. Of course I had to ask who has made a word cloud into shapes--and lo and behold: Tagxedo!  

Wow, this month's words make for a mean fish! It might even be better than "The Useless" way to characterize my journal. ;-)

Tagxedo is the coolest thing since Wordle. When I was writing Wordle comet and Wordle footprint to describe the wordles generated on my site in July 2009, I wondered how long it would take for someone to do image-shaped wordclouds. So, Tagxedo went beta in April 2010. Do look at the gallery!

Well, if I wasn't so busy...

Lest your daily procrastination be underserved, may I suggest July 2010? It has lots of pointers elsewhere. And if you need to be reminded that I'm about more than ♫rah-rah boom-de-ah-dah, you can try October 2010.

1/22/11 I'll ... Never Be Alone Again

Cindy Kallet and Grey Larson's ♫Back When We Were All Machines is wonderful!


And just think, you need never be bored again. ;-)

1/23/11 I think this video stands to be viralled--if you do your part (ok, so today it has 4,768 views).  :-)

Folk meets social-tech commentary. Just think, what would Woody Guthrie be writing about today/where are our social alienations now? In what new ways do we make life meaningful and amplify man's greatest aspirations? And oppress?

Deeply rooted (a)social behaviors (the great, the good, ..., the bad) amplified on tech... raises an interesting set of issues, doesn't it?

1/23/11 Imagination Makes the Difference!

I (re)watched Jim March's Don Quixote's Lessons for Leadership movie with Dana last night, and then saw this note that I jotted a year ago (well, I scanned it on 1/2/10):

What I meant was when two people see the same thing, and one sees it as extraordinary and the other as ordinary, imagination and state are playing a role in the difference in perception. Don Quixote's willingness to see the extraordinary we may see as addled or as a gift. And therein lies that same delta (expansive imaginative interpretation)! I think Jim March's treatment, his selection of issues to treat in just (over) an hour and his dealing with them is brilliant!

When I ask architects to think of a leader worth emulating in their field of experience, they often can't bring someone to mind. And I think it is so unfortunate that we have such unrealistic expectations of what an exemplary leader is. So I liked the way Jim both embraced and debunked those myths we carry around. When we make leaders out to be once-in-a-generation types of people, how are we going to see ourselves as leaders, and set out to be great leaders in our circle of endeavor? We tend to think the issue has to be of historic proportion, a cause of great human magnitude, and we'd have to have qualities to match--the oratory skill of a Martin Luther King, for example. But the need will give us the words. If our cause is the redesign of a piece of the system, that doesn't demand the same order of oration as equal rights, but it does demand its share of persuasion and changing of minds. "I have a dream" is fitted to the language of our context, and the language we use may be no less inspiring--just relevant to those we would persuade, influence, bring along.

There is so much in Jim's treatment worth commenting on but I'm, you know, busy meeting deadlines. Still, I can't resist making this observation, since it also fits this "the delta lies in state and imagination" notion. When it comes to joy, how many people with lives as (extra-)ordinary as mine feel they don't have much joy? In all the have-to of life, the routines, the battles with chaos in endless chores, how much room is there for joy? And Jim goes right after that with the first characterization of joy. Joy in engagement. Joy in putting one's shoulder to that rock--or piano--and pushing it uphill. Not because that is easy, or guaranteed by sheer dint of labor, but because the world will be better if'n we manage to make it so. And it is already better for the trying. Engagement in something we believe is meaningful is a source of joy. Joy in the glorious all-out doing of it. Runners experience it. Thinkers experience it. Lovers experience it. The body is chemically set up to reward behaviors by which the species thrives, but the human imagination is perfectly capable of giving these biological stimulants new meaning that extends their power. Of course, if we get no joy from our work, it may be that we're doing the wrong kind of work for our spirit, not following our Bliss. And maybe we just expect there must be more to joy, so we tuck it away mislabeled and lose our capacity for joy. Yet as soon as we note that there is joy in enjoy, we find that joy, beyond enjoyment, is more our experience. Joy, Bliss. And Glee. Or the pursuit of our aspirations, connected to where and how we find meaning, connected to commitment. Or Angels. If you like.

I love how Rilke put this:

"Perhaps all the dragons in our lives are princesses who are only waiting to see us act, just once, with beauty and courage. Perhaps everything that frightens us is, in its deepest essence, something helpless that wants our love."

-- Rainer Maria Rilke, Letter 8, Letters to a Young Poet

Perhaps how we see joy is exactly what limits us from its flood. Perhaps how we see the leaders in our experience set is exactly what limits them; we cast them in the shape of the smallness we see. And we cast ourselves. We need to see others larger, and ourselves larger.  In Jim March's movie, Cory Booker says:

"If we see no angels, it's because we harbor none."

Cory tells some of the stories that led him to that insight in possibly the most powerful keynote address I've read; here is one:

'She looks me up and down and she goes, “You want to help me?” And I go, “Yeah.” She looks me up and down, and we exchange some more words, and she goes, “Well if you really want to help me, you have got to follow me first.” I say, “OK.”

This woman pushes past me, closes her door, walks down five flights of stairs, walks through the lobby of the building, walks through the courtyard, walks onto the side of the street, walks through some pharmaceutical salesman, at which point I am standing close to her, and she walks into the middle of the street. Now I am in the middle of one of the largest boulevards in the neighborhoods in Newark. She swings around and she goes, “Boy, tell me what you see around you.” I said, “What?” She goes, “Tell me what you see around you.” I said, “OK. Well, I see some high rise public housing.” There was an abandoned building that people use for nefarious things, and I said, “I see that.” And I talked about the graffiti and just described what I saw around me. She looks at me and shakes her head and goes, “Boy, you could never ever help me.” And she turns around and storms off.

I am standing there in the middle of the street thinking to myself, “What the heck just happened?” So I run after her and I put my hand on the back of this elderly woman and I say, “Ma’am, what are you talking about?” She whirls around and she says to me, “You need to understand something boy.” I go, “What?” She says, “The world you see outside of you is a reflection of what you have inside of you. If you are one of these people who only sees problems or darkness and despair that is all there is ever going to be. But, if you are one of those people who see hope, opportunity, and love, then you can make a change and help me.” She walks off, leaving me there in the middle of the street.'

-- Cory Booker, Affiliate Summit 2008 East Keynote Address by Cory Booker by Shawn Collins on September 5, 2008

You really should read Cory Booker's full address! You know me--I'm not into imperatives. But Cory's way of telling touching stories to teach is amazing! And the lessons he teaches in this address outstrip any book on leadership I've read. And that's saying something!

1/24/11 A Kludgy System...

Visualizing the cost of the Kludge--the team starts to feel like they bear the weight of the world!

Several years ago, I had this image sequence in mind, described it and Joe Ficko drew it for me, to illustrate this slide. The system starts small and manageable, but as the system grows in complexity, if kludginess grows too, it starts to feel oppressively like the team bears the whole weight of their world on their shoulders. That, in a nutshell, is the unbearable cost of technical debt.

So, yes, it helps to be clear that when we "seize the moment" incurring "technical debt" to garner the position of early leader in a market, we have made an investment we need to pay interest on. Which is to say, we need to spend explicit cycles refactoring, recrafting, testing and documenting the system. That said, I do believe that we can serve our teams even as we "seize the moment" by applying design thinking (making things intentionally better) from the get-go. And design thinking must be self-documenting--in drawing and describing our intentions, we have to think clearly about them, and we improve the thinking by that process and by exposing it to other collaborating minds. And self-testing--we have to test our designs as diligently (though with the [in]formality that fits the medium) as we test code. Not BDUF, but quick agile cycles learning with the cheapest design medium that will serve to clarify the "game shaper and game changer"-level of concerns of "this extraordinary moment. Yadda yadda.

Never confuse activity with productivity. It is not what goes in your end of the pipe that matters, but what comes out the other end. Everything but intense thought, judgment, and action is infected to some degree with meaningless activity. Think! Judge! Act! Free others to do the same!

-- Dee Hock, The Art of Chaordic Leadership

"What is design? What makes something a design problem? It’s where you stand with a foot in two worlds—the world of technology and the world of people and human purposes—and you try to bring the two together."

-- Mitch Kapor, Software Design Manifesto, 1990

Image above: Copyright Bredemeyer Consulting. Used with permission. ;-)

A very private unknown artist dies. Her obituary is posted and the next day John Maloof Google's her name, and finds the obituary notice. John Maloof, two years earlier had acquired a large proportion of her work, largely in negatives. His interest in, and appreciation for her work had been slow to take root in him--it was in negatives and he wasn't a photographer. Isn't that timing something though?

Vivian Maier's work is remarkable. The story she tells in images is touching, compelling, impressive, ... my mind is too stunned to summon all the words I know belong here!

Thanks to Daniel Stroe for pointing me to the story and photos on BBC News and John Maloof's blog. I'm ever indebted to my scouts and Daniel especially! Well, naturally I had to scout around a bit myself, to discover more of the story of this woman who visually told the story of a city's people, the story of times a changing. So stumbled on this:

Westerbeck explains that Maier’s work lacks the level of irony and wit of some of her Chicago contemporaries, such as Harry Callahan or Yasuhiro Ishimoto, and unlike them, she herself is often a participant in the shot. The greatest artists, Westerbeck says, know how to create a distance from their subjects.

Yet Westerbeck admits that he understands the allure of Maier’s work. “She was a kind of mysterious figure,” he says. “What’s compelling about her pictures is the way that they capture the local character of Chicago in the past decades.”

-- The Life and Work of Street Photographer Vivian Maier,

Doesn't that strike you as rather pompous? No wonder she was private! One of these days we are going to say that there is a form of art that has been dismissed, I'm sorry to say, too often by so arrogant a tarring. It is the art of the people, art that knows and expresses something about what it means to be a person, and to be a person encountering people. Thank goodness for men like John Maloof! Really, one has to trust one's instincts, as Vivian Maier trusted her own. John Maloof has good instincts, and it is no wonder Maier's work found him!

Well, I am much in love with M C Escher's work, which firmly places the artist in the art. Escher's Eye, for example, richly informs I think about deadlines. ;-) Gotta go!

Except... I have to tell you. I have a slide in the second half of the Making It Visual presentation (that you haven't seen yet) that is about the detail that is included, and the detail that is occluded.  And Vivian Maier is a master at choosing the just-so of detail that is a compression rich with meaning and story. That is a component of what we are going after in our art of architecture. And while I'm being outspoken, let me say I believe there is art in software, including architecture. At least, it is there for those who make it so. Hidden perhaps to Westerbecks, or hidden without a guide to reveal it and tell its story.

This was a woman whose passion for her work dominated her life, her brilliance is astonishing, and Westerbeck is dismissive? Isn't "the greatest artists distance themselves" just a little too trite to be trotted out just now? When someone is redefining the rules, stodgy formulaic responses seem a little out of place. Vivian's work captures spontaneous unstaged moments, but that doesn't make them less objective. Isn't it sufficient that an artist distance himself enough that he can become a fair object of study? How close and yet how distant Escher had to be from himself, to etch mans reckoning with mortality in his own eye!  That is a lot more distant than someone who has studied himself so little as to blandish a unique and crystalline vision with some leveling schoolbook treatment!

Smile. Uh, now I have to go and work out to Marx Brothers so I can figure out how to make the point I want to make being less unkind to the person voicing the "designated alternative viewpoint"! ;-)  Then... there's deadlines... and there's Escher's Eye. ;-) And Marx Brothers. What can compete with that... right now, anyway?

Later: We really have to get over this notion that the artist should have no part in her art. Life is the greatest artist of all, and we are each complicit and deeply enmeshed in it--whether we choose to write "object poetry" or to create an entirely subjective expression, if we just write what life tells us (in whispers and gasps, in shouts and cries, in images and tones), we'll be true to our own art. Frankly, it is audacious and courageous indeed to put oneself into a work that will be judged--by muggles even. Life is the greatest artist? Well, what better happy coincidence of paths than to go from writing this post to watching Duck Soup? Life's sense of high farce, life's sympathy for our predicament, life's timing!

Yes, we too put ourselves into our "so impersonal, so objective" systems. We do, and we should. Back to Escher, this time to Gravity... I and others, have used it as a visual metaphor for the "big ball of mud" of a software system, and it is great isn't it--each developer puts her and himself into the system, and it transmogrifies into its own emergent form-shifting form...

I am so happy for my scouts. And our resident Marx Brothers fan is a great one. I've said this before, but I'm happy to repeat myself--where have I been all my life? I mean, stochastic processes and dynamic programming are getting their day in the sun with business analytics and BI... and perhaps I had to do that, to appreciate Duck Soup... Well, there's also the small matter of preferring outdoor runs and rambles... If you have to workout indoors though... video on demand/Duck Soup is a good way to go.

1/25/11 Adventurers

Tracking down a neat visualization of influence maps, I stumbled by chance on the cryptoforestry blog--scanning across the sequences on cave drawings (early visualization of social systems and more durable recordings of tribal memory--we still have some of the pictures but not the oral accounts), I was intrigued enough to read into bits and pieces, rising* to the most recent post on Exploration Fawcett. And was drawn by "he was an acute observer" to this passage:

"It took me a long time to start reading it. I thought it would be tedious reading with undertones of obsessiveness and dullness and the cover didn't help either (and it is a trash book, it does not mention year of publication). It turns out that Fawcett was a headstrong but friendly humanitarian with a Victorian mind over matter and an acute observer. If Indiana Jones was not a film by Steven Spielberg but a book by Jane Austen this would be like it. Amidst the atrocities of the rubber boom Fawcett combines a firm grasp of the situation as a social wrong with a never wavering sympathy for human frailty. His stance on the Indians, believing their belligerence overstated, is incredibly modern and suits him well in his explorations. He is more Ray Mears than Bruce Parry.'

--  cryptoforestry blog, 1/24/11

Sounds like a great book to explore exploring!

That "never wavering sympathy for human frailty" is so important, don't you think? If we are to "harbor angels" we need to have sympathy for our own frailty, and then it is a deep well of empathy with others--this, you see, is a great antidote to arrogance. We must be optimistic and confident we can bring about the change we see, without being dismissive and self-aggrandizing.  

* I like to follow the trail of a person's mind, and blogs are "up-side-down" ... unless you're visiting regularly with that mind... 

So much of our time as architects and developers is spent figuring out what the system does, with the why's lost to the wash not just of team attrition but the fallibility of individual memory and the rather selective nature (and active forgetting) of "tribal memory". Valiant adventurers looking for lost cities? Indiana Jones seems not so far off a hero, looked at like that. ;-) And this Fawcett, with his determined ability to "make his own choices" and survive with his own adaptations of mind seems an intriguing figure.


1/25/11 Golden Carrots

This from a Bredemeyer Consulting mailing list signup:

"Love what I've seen so far - very concise and easy to follow. Thanks!" -- Adrian

Lest all the words and playful thoughtfulness of my journal fool you, I can do concise, simple, and straight-down-the-line minimalist action oriented. Here, I dance with angels and wrestle with demons, complexifying in order that when I simplicate it is knowing that I did my own form of due diligence.

So tell me, as we hurtle towards the 5th anniversary of this journal--does it do me more harm than good to share it? I'm astonished and touched by the "return visits" stat on the dashboard for this site, but the 1 hit bounce-offs make me wonder if I do myself a disservice to allow it to be accessible. I do feel sympathy with Vivian Maier, feeling inclined, in the absence of encouragement, to want to shield my notes from the kind of disparaging assessment that a bounce-off signifies.  It seems that the potential for harm is higher than the potential for good; indeed, I know of no good that it does.

1/25/11 Evening Tracks: My Little Jaunt for Some Light Relief

Here's a neat piece of our history: Developing Software for the Space Shuttle

As for other possible solutions, Parten says, "the only right answer is the one you pick and make to work"

-- Developing Software for the Space Shuttle,  Chapter Four, Computers in the Space Shuttle Avionics System -

Robots and amplified intelligence


Control and/or Monitoring

1/25/11 ... Climate Change


1/28/11 To Trace, or Not to Trace, that is the Question

I have been a poor scribe of my adventuring this past week! No, I wasn't pouting because no-one sent early 5th birthday greetings to this journal. ;-) While I think this is quite the most exquisite request for feedback I've encountered:

"The mind is so near itself it cannot see distinctly" -- Emily Dickinson

in the case of my journal, I see the ill in it well enough to realize that what is thought is better not told!

And yet,... do you think my journal so much less than that of another adventurer? A Fawcett, for example? I know. I know. The book. The book. Actually, three. I think you'll like them. I like the form that's emerged for each, and that's so critical don't you think? To have the form that invites filling? Why three? We need the "hoppers" so one doesn't try to be more than it should... there'd be more, but we have to focus. ;-)

And this form, this trace of my exploration, my adventuring-encountering with minds of others is a form I enjoy -- to a fault! -- though it is generative too.

So, do you think we should accept an invitation to write a chapter for another book, or press myself and Dana into getting these books done already?

Oh well, this seems a neat quote to tuck away:

"The sailor cannot see the North, but knows the needle can." -- Emily Dickinson

It may, for example, come in useful talking about visualization/dashboards. :-)

When I read this:

"Often, too, she was obscure and sometimes inscrutable; and though obscurity is sometimes, in Coleridge's phrase, a compliment to the reader, yet it is never safe to press this compliment too hard." -- T. W. Higginson

I thought of code--where inscrutable might be taken to be entirely a compliment to the writer... which called to mind:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler

I am looking forward to carving out some hours to read Martin's DSL book!!

Well, the neat thing about architecture is that there is no confusion: architecture is for humans to understand. Busy humans. Humans who have to live with it, or its consequences. And therein lies quite the rub!

Three books. One beautiful little thing that readers of this journal will, I think, quite love. The Action Guide. And a third more expansive. The full-featured book, if you like. Top of the product line.


1/29/11 On the Whole

Reading the conversation bouncing around the topic of software craftsmanship... a few things occur to me...

Over the timeframe of the last Agile conference, I paid attention (as I do) to the tweet streams of the likes of Martin Fowler and Bob Martin, and I know there was concern about a preponderant emphasis on the social/management/teaming aspects of agile and lean, leaving a yawning gap on the technical side. Well, hello, welcome to our world! If we are going to "pull up" and go to a conference, it's going to be to get what's new-new, what's sizzling hot. Leaving Martin and Bob to conclude that agile and lean have been hijacked by those who pay attention to the project management aspects... Hijacked, or an indication that it is just time to say agile and lean have moved into the "mature" phase of life where it's less about creating an identity and more about settling down to business, taking care of responsibilities?

The Software Craftsmanship Manifesto communicates well what Uncle Bob says it intended to... "We are tired of writing crap." And that is a very sorry state of affairs! Unfortunately it is a state of affairs that comes of how we set our world up. Crap isn't what software folk want to write, or set out to write! It is a symptom. Not a symptom of incompetent people or bad intentions! But a symptom speaks of a need, an opportunity for a new movement. 

Ironically, while we still have very serious technical challenges to address on the path to great software, there are also very serious non-technical challenges that have to do with how we set things up. The path to great is multi-faceted. It has to do with art--with exploring, making and communicating meaning and beauty. It has to do with rigorous engineering--codifying, transferring and applying design knowledge; in our field we mainly do this in the form of patterns--or the more nuevo so more tech-sexy kata (as it is used in software). It has to do with craft--with experiential learning and skill that comes of paying attention as we work ... and contemplating the kōans of the sage masters of the field... And it has to do with the teaming, communication, collaboration and work management issues. The last set will dog the technology issues no matter which new "camp" they move to, because they are part and parcel of creating systems when, bother, people have to work with people not just machines to create something complex.

Software is a vast landscape. It stretches from (yes, love 'em) end users programming in Excel to kids and hobbyists programming their Mindstorms robots to apps to enterprise applications to... the good folk programming the power steering in my car that bails when the air pressure in my tires falls below a certain point... We need to embrace this diversity, while at the same time making room to attract those who want to be "rock stars," who want to be known for being the superstars of our world -- our craft, sometimes. Our very, very rigorous engineering discipline, at others.    

Again, the software field is a vast landscape. And it needs to be. Our dependence on software, on this "fabric" we have draped so pervasively, is so great, our appetite for what software enables so vast, we can't depend only on a select set of superstars. We must not (continue to) make it a field that expunges women and minorities. We must not make it a field that repels gentle folk who don't want to have to hack it in a competitive arrogant exclusivist field. Sure, we need to have spaces where that's ok, because we need the people to whom coder superstardom appeals. We need to have languages and programming paradigms that are accessible to a broad base, and we need to have the power languages and paradigms for systems that demand it. We need to have venues to challenge ourselves to stretch the limits of software--the aesthetic limits, the limits of pure beauty, the limits of utility, the limits of our ability to tackle the most stringent demands on what humans can make machines do! And we need to have venues where we just plain make stuff work. Everyday stuff. And extraordinary. And frankly, some of the most extraordinary stuff being done with software is not being done in what we recognize as our profession! Mechanical engineers. Biologists. Musicians. Artists. People are using software--they write--to expand their intellectual and biomechanical reach in all kinds of domains, and while they write code, their identity is other than software developer.   

That makes software rather unique. So, one way of looking at the energy the conversation has generated, is to say "yay us!" Craftsmanship is important. The art is important. The utility is important. Delighting users--important. Not creating shoddy stuff--important. All these different dimensions are important. Some more important, depending on context. The context may be individual need to excel. I say "amen to that." The context may be software that just has to fly, no matter what. Many contexts. Driving many needs.   

I work very much at the cusp between the technical and the social/interpersonal and the business so this "working at and across boundaries" shows up in everything I do and while I try to get enough clarity to find the lines in a master butcher (Cook Ting) kind of way, this is a complex world full of interactions. We look for the lines between yin and yang, but we also need to recognize that these make wholes. Not holes.

As holes--rat holes--go... here's my 2c: certification of the kind that costs a lot, creates a class system that is about money (big corporate money) more than ability. Again, I come back to the span of contexts in which great and sometimes shoddy but still utilitarian software is being written. I'd hate to see this diversity, ingenuity, and spectrum of players curtailed. On the one hand, I don't think it could be. And on the other, I've lived with the ways our field tries to expunge diversity and create a uniform troupe of superheroes.  And trying to raise the barriers to entry is just one way we'd be trying to make it an exclusive province. Pure arrogance and dismissiveness is another. We've done enough damage simply with the latter.

So let's have our technical conversations, and drive the frontiers and the state of our practice. And let's have places where those who want to hang their hat of allegiance can do so. But don't let's try to foist uniform bars on our field, nor foster the notion that as a field, as a whole, we are about elitism. That's not healthy for a field where "waves of creative destruction" emerge from college dorm rooms to reshape the competitive landscape. Where moms write code with their kids to show them an underpinning of the future. And countless million other scenarios!

Holes. Gosh, I hope I didn't just dig one!

(This tongue in cheek piece shows that at least we can smile at our own earnestness.)

half full or half empty, it's up to you. But whatever your answer is, it is quite true. By Sara B. Age 10.This from Dana:

...American on Purpose, the autobiographical story of Scotsman turned American comedian and late night talk show host Craig Ferguson. In the preface he says:

Little League had taught my son that failure is not disgrace. It's just a pitch that you missed, and you'd better get ready for the next. My son and I are Americans. We prepare for glory by failing until we don’t.

I watched Howl's Moving Castle with Sara last night. Hayao Miyazaki is a genius at wrapping his penetrating message in anime that is as unlimited as the imagination and is at once full of the magic of childhood and yet deeply profound so that as one "swims in" the contemplation it invites, one finds still more gems of insight. A girl is transformed by a spell into an old woman, and this all by itself is full of on-the-face-of-it and beneath the surface insight. Her orientation to seeing the bright side is her blessing.

We prepare for glory by failing until we don’t. But we do so with a kindness towards ourselves. We may call it failing or, more positively, call it trying, exploring... Though sometimes it can feel like there is no better word than failing. Trying to get the organization to "repay technical debt," to rationalize the code base to provide a better platform for product derivatives, to explore an innovative product idea--anything that requires convincing and direction setting through persuasion rather than control over budget, can feel like a Sisyphusian path, or at least one beset with setbacks and obstacles that consume us seeming pointlessly. All the travails of architecting. Yet, don't we at least mostly enjoy the endeavor? If we are playful and joyful, resourceful and resilient, the trying is mostly invigorating.

Seeing the positive is not a vacant attitude we ought to scorn and deride.

It is puerile to assume that people who seek out the positive are superficial careless thinkers, or servile flatterers! I would no more assume a dark and curmudgeonly person to be a shallow fickle creature than a joyful optimist! Optimism is a state of mind that, in a world where hurt and darkness co-exists with joy and light, is no easy achievement! -- moi, 3/30/10

The protagonist of Howl's Moving Castle redeemed first herself by this ability to see the good even in desperate circumstances, and then she redeemed those she loved--because though she saw them clearly as they were, she also saw them as their best selves and loved them for the greatness she saw. That was her gift. Her talent, and what she gave of herself.

We are each complex bundles of lesser and greater qualities, of foible and glory. We are finite beings, with finite time to create ourselves, and build our products and livelihood and manage all that has to be managed, coped with, and achieved. Love tenderly embraces the frailty without derision, and exults, celebrates and adores the greatness.

Still... we all suffer our humanity. The more we extend it, the more vulnerable. On Friday, Sara exasperatedly said to me "why do you say so much that no-one pays attention to?" It was one of those moments where a spot of temper shines a glaring light, but little does she know the full (vast) extent of it... ;-) 

"I am quite aware -- that in a setting filled with faculty, friends, and parents -- the supply of free, unsolicited advice already far exceeds any demand for it."  -- James March, University of Alberta Convocation address, 2009

The Useless. Indeed!

Five years of it! Ugh!

Image: By Sara B. Age 10. Eating alfresco at a restaurant near the National Zoo in DC last spring, Sara looked at her water glass and penciled this picture and wrote these words:

Half full or half empty

It's up to you.

But whatever your answer is,

Either one is quite true.

Amazing that a 10 year old can see that one thing can hold two simultaneous truths, while we battle so with paradox.

1/31/11 Context Factors!

In our Architect Competency Framework (2002), we have only one band for technical, but this is a band that distinguishes the architect from an already experienced developer or technical specialist. This technical foundation is expressed in the "level 1" technical skillsets. To be very clear, it assumes depth of experience in the technical area that is a foundation--a foundation gained in advance of becoming, and sustained and built upon in order to continue to be, an architect. [If we were to try to create a program that "out of the college box" produces architects, the founding assumption set would be entirely different! We would have to create internships and an extended academic program, much like building architecture and medicine. I just don't see 4 years of undergraduate class work and the size of projects that can be woven into that context being enough.] That said, in the technical competency elaboration, I probably need to say more, for example, than "Designs mechanisms to address cross-cutting system concerns." That is a great big bucket of responsibility with competency implications right there, and deserves to be elaborated! :-)

Even so, what we were doing in 2002 (actually the origins of that competency framework was created for a class to help managers understand how to support and grow their architects back in 1999), was creating awareness that the soft skills are important to creating not just good, that is technically sound architectures, but architectures that are right (meet the conjoint set of stakeholder needs in ways that are differentiated and economically, technically and organizationally viable and sustainable), and successful (actually delivers that value). Now, 10 years (give or take a year or two, depending on how you want to count) later, that is not a done deal. There is a perennial thrust to reclaim "architect" as an entirely technical role, one that focuses on the toughest technical challenges and forget the business and soft skills fluff except in so far as it is needed to get a technical solution adopted without (quite so much) demur. Those who want "soft skills" to sugar coat a technology pill that the organization is balking at swallowing, are coming at this from the angle of technology push. The whole point of the competency framework is that while sometimes technology push is exactly the right thing to do, it is from an understanding of the business and customers that a strategy is developed. A strategy that may be technology pull, or technology push, or some of each.

When I'm working with architects on interpersonal effectiveness, I raise the question of ethics. Working with some virtualization "architects" (the technical specialist kind), I used the Derren Brown "red BMX" clip as a prompt for that ethics discussion. One of the architects, in absolute earnestness, asked why we don't just use Derren Brown's techniques to make customers want the solution we've decided on. Doesn't he have a point? I mean, look how happy the guy is with the BMX bike! Wouldn't that make everything just so much simpler? We get to decide what we want to do. Then we spend a few minutes with the stakeholder, and they're ecstatic with what we put in the box. Well, if you don't see the fallacies in all that, do I have a journal for you to read! In short, yes, we do want to make stakeholders happy--even that kind of kid-bouncy excited happy. But we want to do so authentically, and with a solution that works in its intended context. In other words, there's just a bit more to be done up front, and along the way, to understand the forces that impinge on the problem-solution. There's somewhat more to be done to creatively and imaginatively, and by bringing experience and expertise and codified knowledge and reasoning to bear, come up with a characterization of capabilities and solution design. Uh, right. All the useless stuff I explore in this journal, that you don't need me to rehash. But also more. So much more.

In short, the architect competency framework needs to be understood to be one that assumes even entry level architects have a strong grounding in technical skills. It focuses on what, beyond the skills gained in the first several years of the technical career, does an architect need to know, do and be.  (This is obviously different for a Business Architect, who instead needs to have a strong grounding in key areas of the business, developing depth of knowledge and the kind of blink insight that is born of experience, and developing business cred.)

1/31/11 Tomorrow--a Clean Slate

The neat thing about this journal format is that each month starts with a clean slate, and a chance to try something new. To fail, if you like, in a new way. So the end of the month is a chance to review the failures to date, and consider what tack to take in the month ahead. Oh yeah, theoretically there's the archives, but ... the current month is already more than enough to fry attention circuits! :-)

Well, that's if we continue to have power through the ice storm over the next two days...

2/1/11 so far so good... the ice is really pretty. When a bird settles on a branch, the tree chimes! Beautiful, but with an edge of foreboding in a world highly dependent on electricity and all the tech it gives life to! The worst of the storm, with lots more freezing rain and high winds, is supposed to hit this afternoon...

I also write at:

- Resources for Software Architects

- Trace In the Sand Blog



- Strategy, Architecture and Agility: The Art of Change: Fractal and Emergent, 2010

- Innovation and Agile Architecting:
Getting Past ‘But’: Finding Opportunity and Making It Happen, 2008


- Links to tools and other resources


Misc. me:

- Other Interests

- Introducing Archman


Sara's Mom (by Sara)Feedback: I can be reached at . I welcome input, discussion and feedback on any of the topics in this Trace in The Sand Journal, my blog, and the Resources for Architects website, or, for that matter, anything relevant to architects, architecting and architecture! Bring value, and I commit to using what you teach me, to convey it as best I can, help your lessons reach as far as I can spread them. I try to do this ethically, giving you credit whenever I can, but protecting confidentiality as a first priority.

Restrictions on Use: All original material (writing, photos, sketches) created by Ruth Malan on this page is copyrighted by Ruth Malan. All sketches by Sara B. are used with her permission. All other material is clearly quoted and ascribed to its source. If you wish to quote or paraphrase fragments of material copyrighted by Ruth Malan in another publication or web site, please properly acknowledge Ruth Malan as the source, with appropriate reference to this web page. If you wish to republish any of Ruth Malan's or Bredemeyer Consulting's work, in any medium, you must get written permission from the lead author. Also, any commercial use must be authorized in writing by Ruth Malan or Bredemeyer Consulting. Thank you.

(Image by Sara B.)


Copyright © 2011 by Ruth Malan
Page Created: January1, 2011
Last Modified: July 26, 2012