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 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. [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 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 the 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.). Architecture 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? 

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? Mirriam-Webster.com and Collins have opposite definitions!

Tricksy stuff!

Tricksy. Hobbit. Oh, did you see today's xkcd? I visited with Dana and Ryan 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:

• Architecture versus Design, Gene Hughson { highly recommended }
• Defining the Terms Architecture, Design, and Implementation, Rick Kazman and Amnon Eden, 2003
• Less is More with Minimalist Architecture, Ruth Malan and Dana Bredemeyer, published in IEEE's IT Professional, September/October 2002

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 in to 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, if you like, clarifying the design envelope and system support for differentiating as well as essential system capabilities, etc.

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.

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?

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!

Ryan came home and headed directly for the piano, inspired to write his own songs for the album he's recording. Ah dreams. But the thing that is so amazing about Tim (who is Ryan's voice teacher) is that he treats Ryan as a peer, as someone he respects and enjoys working with and that makes Ryan just bloom with the joy of aspiration worth vesting oneself in. So Tim is, you see, talented in many ways. Being talented not just in playing and composing music and writing songs, but talented also in working with people, different people in all their remarkable uniqueness, is gifted indeed. This was clear in his concert, and the talent he draws out in others serves his talent well, for in each of the quite different ensembles, Tim's presence was strong--directly, and in what his perfect foil brings out in those he collaborates with.

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

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

Correct

                         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!

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

• Skype has big plans, and brings "use cases" to public radio parlance!
• more evidence that innovation is alive and well

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)!

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:

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:

• Architects and observation

• Making It Visual

• On the education of an architect

More Feynman:

• Feynman: from a new point of view:  ☼1, ☼2, ☼3, ☼4

• Feynman: Let's see what that means

 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:

• How Facebook Ships Code January 17, 2011

The post about the culture at PayPal is interesting too.

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”³.

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”⁴. 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.³.

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.

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

Um.

Ciao!

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.