contacts and protocol design

• Arguments and Results, James Noble

• Bringing Speech Acts into UMM, Maria Bergholtz, Prasad Jayaweera, and Paul Johannesson, 2002

• Consumer-driven Contracts, Ian Robinson

• How to Design a Good API and Why it Matters, presentation by Josh Bloch (of Google) on InfoQ, 2006

information hiding and encapsulation

• information hiding, wikipedia

open/closed principle

• open/closed principle (OCP)

• open/closed/open principle, Kent Beck  [You might want to relate this to Table 1 in The Art of Change, and the section of System Integrity.]

case studies and examples

• The Control Software Architecture for the Green Bank Telescope, by Mark H. Clarka

technical debt

• Technical Debt -- Definitions and Resources, Brad Appleton, 23 June 2009
• TechnicalDebt, EstimatedInterest, TechnicalDebtQuadrant, DesignStaminaHypothesis, Martin Fowler
• ☼Debt Metaphor, Ward Cunningham, 2009, and The WyCash Portfolio Management System, Ward Cunningham, March 26, 1992
• Design debt, Refactoring to Patterns, by Joshua Kerievsky
• Technical Debt, c2 wiki
• Quantifying the start afresh option, Israel Gat, Cutter blog March 22, 2010
• Technical Debt and Design Death: How to ensure you can deliver business value in the future as well as in the present; by Kane Mar and Michael James, 23/7/2006
• Managing Technical Debt - a whitepaper, by Steve McConnell (requires registration, which is free, but also see the blog-entry 10X Software Development - Technical Debt) [via Brad Appelton]
• Design debt economics: A vocabulary for describing the causes, costs, and cures for software maintainability problems; by John Elm, IBM developerWorks, June 2009
• Managing technical debt, Tom Brazier, Feb 2007

tools -- static analysis (most focus on modularity, coupling, granularity, etc. issues and have implications for making technical debt visible)

• see Software visualization tools and resources, Ruth Malan

tools - performance analysis (useful in making aspects of technical debt visible, like code coverage)

• list of performance analysis tools, wikipedia
• dynamic program analysis, wikipedia

In the work we do with architects, I have assumed the foundation is there, but I wanted to have some level-setting background material for those who need it. 

7/25/10 Design Thinking

Kent Beck's Responsive Design Lessons So Far (listed as "The Tour") is awesome! And guess what--one of the lessons is "play with pictures"! With pictures! It's not only this Q<= who ☼talks in terms of pictures! Oh, right, I do so because I want to include group graphics, rich pictures, ad hoc diagrams, and models--UML models, SysML models, analytical models, etc. Yes, the good stuff of Visual Architecting.

There is a "palette" of diagram types in this post. It's a nice idea, and links to my BI pyramid model (that leverages/refers to David Sibbet's knowledge model).

I mentioned I'm reading Change By Design--it's been on my reading stack for months, but I was too busy writing about design thinking to read Tim's book!!! Oh well, I'm reading it now. I love the story he starts with. I noticed right off (I scan the pictures first, what can I say) that he has a diagram that is our "circle of innovation" model, just labeled "desirability," "feasibility," and "viability" with arrows instead of circles. Kent Beck uses a three legged stool instead. We have a client who has done the same (used the stool image, that is). Well, of course Tim Brown has a section on visual thinking. I like this point: "drawing forces decisions." And a section of getting our hands dirty, namely prototyping--building to think. You might remember that I've pointed to Tim Brown's talk on TED on creativity and play. The really neat thing about Tim's book is that it is full of stories.

7/25/10 Visioning

Kent Beck's Write your own fan letter rivals Amazon's "write your press release before you start," and Jim Highsmith's Design on a Box (I've called it a "cereal box vision" after Luke Hohman's game in his Innovation Games book). If you've followed along (e.g., attended a workshop, read Getting Past "But", looked at our VAP posters, looked at our Action Guides, read this journal, or my blog, etc. Grin), you'll know that we like to use a derivative of The Grove's Cover Story Vision graphical facilitation chart and format. It combines the good stuff of group graphical facilitation, and there are the dimensions of the "voice of the customer" (what great things users, buyers, folk in the value stream are saying) and the "voice of the business" that are important to capture, to make the vision compelling and vivid to various stakeholders and also to establish the charter for important things that need to be done in the system and its architecture. (It is hard to get to the big value delta in architecture/design unless we are clear that there are goals that we will make haphazard progress toward by trial and error and without explicit reflection and intentional design.)

Still, the fan letter is minimalist and agile, and a good way to get the first level of buy-in to your idea, so you can get the broader input you need to create the level of vision that will inspire and align a multi-functional team-of teams--in Getting Past "But" style.

7/27/10 Remembering

July is a month for celebrating and remembering several people who touched me deeply.

7/28/10 Some Interesting Numbers!

Anyone seen an update on numbers like this?

For example, this is a pretty old number (from the start of my career -- that's an old number!):

"Studies of software maintainers have shown that approximately 50% of their time is spent in the process of understanding the code that they are to maintain (Fjeldstad & Hamlen, 1983; Standish, 1984)."

-- Jussi Koskinen, Software Maintenance Costs, 2003

I need to scout for more up-to-date numbers -- if you of know of any, please let me know!

7/28/10 Hard to Catch

It is better to watch herons from the kayaks than to photograph them, since it is hard (for me anyway) to hold the camera steady enough (on somewhat choppy water) for the amount you have to zoom in on these rather timid birds. But, of course, that hasn't stopped me from trying. :-)  (And no, I haven't braved taking my SLR out on the kayak, though I'm getting there.)

Hobie mirage drive kayaks are not graceful and elegant like a (traditional) sea kayak, but they do make for a great workout and like minivans, they are kind of the family compromise transport. They are very stable (and being leg powered, use the strongest muscle groups), and even when Sara was 2 or 3 years younger (so 7 or 8 years old) I wasn't worried about her being alone on her Sport (that she inherited from Ryan when he moved to the more graceful Revolution). We can cover pretty good distances, though last time we were out with the kids, I spent a good bit of the return trip holding Sara alongside and pulling her along--but such are the options on these very stable kayaks.  Anyway, with it being too hot and humid to run, we're taking advantage of Lake Monroe being just 10 minutes from home to put-in, and within minutes from there getting out into the wilderness where heron are abundant and the bald eagles are so exciting and magnificent to watch.

During yesterday's few mile lap on the lake, my camera fogged over and quit (it's very humid), so I gave up on trying to find a way to capture the scene (the forested hills alongside the lake diminish in the context of the expanse of the lake and the sky, and it is hard to find a composition that does the loveliness justice). The moment I stopped focusing on composition, the world became noisy with cicadas! It was like they'd kept quiet all the time I was looking at the scenery and the herons with a frame finding view--but of course, it was just my attention that made it seem that way. In Eldest, Eragon is under training in the skills of a Rider, and he immerses himself in the perspective of an ant colony and discovers many tiny details about their life and society, but his mentor is disappointed, because he could say nothing about what else was happening in the forest while he so focused on the ants. Eragon is a dragon rider, and he has the advantage of being more than human. But we, we have this characteristic that what we are paying attention to, shapes what we perceive and pay attention to. So, we have to learn to shift our attention from the detail to the system, to become aware of the context, and the interactions, the trace between goal, strategy, tactic and outcome and the tradeoffs and balancing that has to be done. And focus on the detail, where that is architecturally significant. The key though, is that this is part of the critical "thinking like an architect" that we have to develop--paying attention to the system, and system outcomes like system integrity and value from synergy (or collaborations among the parts, and between the system and other systems and entities in its context). It is also why the architect role should not be seen and staffed as a "parachute in/get yanked out after architectural design" kind of thing. Software systems evolve, and this evolution can be entirely emergent from happenstance, or guided and reflected on and intentionally shaped. For this last to happen, there needs to be a role--and a person (or team, in very large projects) in that role--that is responsible for the architecture. If the architecture is "everyone's responsibility" then that focus on the the next code drop, the next build, the next mod to get the current user story working, will dominate attention--and architecture will subside into inattention. Architecture requires tradeoffs, tough choices that have to be thought through and advocated. Attention that has to be wrestled away from the detail, and paid to the system, to systemic forces, to cross-cutting concerns, to the wash of entropy, to the pull of vested interests that constantly work their agenda.

And you thought that for once, just for once, I wasn't going to write about architecting! Ha!  

So, how did those Hobie kayaks fit in? Well, compromise and tradeoffs come to mind. Gosh, family life is very much about compromise and tradeoffs, isn't it? But I also learn so much I wouldn't otherwise. Like, I'd never have imagined I could power two kayaks (an extra ~150 pounds, given the weight of the kayak and child) for an hour... I mean -- little me! And that becoming-real-through-being-loved thing, that's cool too!

It is funny how things come together. I referenced Ivan Sutherland's classic "Technology and Courage" essay on my "Weaving Ruth" post, and it occurred to me while kayaking with just my thoughts for company, that Courage is a wonderful treatise on risk. Which brings me back to the topic I started the month with (finding stories for the "inspire" part of our "inspire and enable' teaching style for a segment of an evaluation/improvement/validation customer intervention/workshop, if you must know). I like it when cycles complete so neatly! [A lot of the essay focuses on academic research, but much applies with little effort in translation to system development.]

7/28/10 Adding "With" to the 6 Interrogatives  

I stumbled on Alex Matthews blog (he has a description with some pointers to tree/heat maps). Well, of course you know we use the 6 interrogatives for organizing access to various content areas on the Bredemeyer Resources for Architects site (have done since its inception in '98, though I'm looking at a site redesign... as soon as I get the book done. Right!) Anyway, Alex adds "With" to the interrogatives. Nice idea! Of course, "with" should point to our "Fractal and Emergent" strategy and tandem architecture paper, should it not? Grin.

Ah, so many opportunities to refer to it. But only one opportunity to be the first to do so! (Here's an overview, if you want to provide a "teaser" along with the link to the download.)

7/28/10 Interesting Window on History  

• Tools for Thought by Howard Rheingold

7/29/10 Innovation and Creativity

These by way of Anne Merkelson of The Grove (on LinkedIn):

• Cover story vision as collaboration game, Luke Hohman
• The Creativity Crisis, Newsweek, 7/10/10

I want to highlight these points from "The Creativity Crisis" article:

'A recent IBM poll of 1,500 CEOs identified creativity as the No. 1 “leadership competency” of the future.'

"To be creative requires divergent thinking (generating many unique ideas) and then convergent thinking (combining those ideas into the best result)."

"When you try to solve a problem, you begin by concentrating on obvious facts and familiar solutions, to see if the answer lies there. This is a mostly left-brain stage of attack. If the answer doesn’t come, the right and left hemispheres of the brain activate together. Neural networks on the right side scan remote memories that could be vaguely relevant. A wide range of distant information that is normally tuned out becomes available to the left hemisphere, which searches for unseen patterns, alternative meanings, and high-level abstractions.

Having glimpsed such a connection, the left brain must quickly lock in on it before it escapes. The attention system must radically reverse gears, going from defocused attention to extremely focused attention. In a flash, the brain pulls together these disparate shreds of thought and binds them into a new single idea that enters consciousness. This is the “aha!” moment of insight, often followed by a spark of pleasure as the brain recognizes the novelty of what it’s come up with.

Now the brain must evaluate the idea it just generated. Is it worth pursuing? Creativity requires constant shifting, blender pulses of both divergent thinking and convergent thinking, to combine new information with old and forgotten ideas. Highly creative people are very good at marshaling their brains into bilateral mode, and the more creative they are, the more they dual-activate."

This, from the same article, is interesting:

'In middle childhood, kids sometimes create paracosms—fantasies of entire alternative worlds. Kids revisit their paracosms repeatedly, sometimes for months, and even create languages spoken there. This type of play peaks at age 9 or 10, and it’s a very strong sign of future creativity. A Michigan State University study of MacArthur “genius award” winners found a remarkably high rate of paracosm creation in their childhoods.'

in the light of this: breaking confining conception. (Implying nothing about my kids, but only pointing out how much leveling our society masses against creative and unusual play.)

7/29/10 For Kindred Seekers

Reading that post (breaking confining conception), I find I like it--it might percolate up as one of my favorite 3, or at least one that is representative. There is so much in that post that is enormously important to creativity and architecting and my role in this field, and it is full of eureka-level convergent insight, playfully written. And, yes, the number of people that will grok it is certainly limited both by its references (like, who has seen The Rockae?) and by its style. So? I expect only extraordinary people to read here--extraordinary, kindred bliss-following, awe-struck seekers (an adaption of Grady Booch's "awe-struck seeking" and "follow my bliss" which itself borrows from Joseph Campbell's 'follow your bliss").    

"Yet it is important to note that following one's bliss, as Campbell saw it, isn't merely a matter of doing whatever you like, and certainly not doing simply as you are told. It is a matter of identifying that pursuit which you are truly passionate about and attempting to give yourself absolutely to it. In so doing, you will find your fullest potential and serve your community to the greatest possible extent."

-- Follow Your Bliss, Joseph Campbell foundation

'Now, I came to this idea of bliss because in Sanskrit, which is the great spiritual language of the world, there are three terms that represent the brink, the jumping-off place to the ocean of transcendence: sat-chit-ananda. The word "Sat" means being. "Chit" means consciousness. "Ananda" means bliss or rapture. I thought, "I don't know whether my consciousness is proper consciousness or not; I don't know whether what I know of my being is my proper being or not; but I do know where my rapture is. So let me hang on to rapture, and that will bring me both my consciousness and my being." I think it worked.'

-- Joseph Campbell, The Power of Myth, 1988, (First Anchor Books ed. 1991, p149) 

7/29/10 Luminaries

I stumbled on Scott "Doc" Andersen's blog the other night, and this post is heart-warming: What or Who is a Visionary.

I will have to write a post on the luminaries that light my sky--which is, of course, an extension of the "Weaving Ruth" post, but also with a finer focus. Grady Booch certainly features prominently among those that light my thinking. Martin Fowler too--more, the more "human" he allows his projection to become. ;-) But there are luminaries, and there are influences, and my influences are so vast and diverse (like Keith Moore, Joe Sventek, Rob Seliger, Dean Thompson, ...)! And there are people who changed the trajectory of my life, and to whom I am most grateful (like Martin Griss, Derek Coleman, and Todd Cotton). Well, lots to think about there! Another time!

7/30/10 Architecture Principles

An Architecture Principle is a normative statement that orients (or steers) and aligns decisions and actions so as to achieve strategic outcomes. That is, Architecture Principles focus and guide decisions, shaping direction to address factors critical to achieving strategic intent (or strategic/architecturally significant system outcomes). Well-stated principles cleave the decision space between decisions in line with the principle and decisions that run counter to the principle.*

Rob Seliger introduced us to architecture principles in the early days (i.e., in the mid '90's) of working on what would become the Visual Architecting Process. We, like Rob, used the guidelines described in Paradigm Shift as a starting point, and to avoid "motherhood and apple pie" principles, we added counterarguments to the template. There are those, like Mark Schultz, who argue that architecture principles "are statements of preferred direction or practice. They reflect a level of consensus among the various organizations within an enterprise." We notice that they are statements of direction or practice that we need to develop consensus and action around, to create focus and align decisions to achieve strategic intent. For example, we might need to change the status quo to implement a shift in strategic direction, or to do something consistently that we have only being doing in isolated instances because it involves hard choices and tradeoffs. If we are going to take a minimalist approach to architecture, then we look to the minimum we need to do to ensure that the right things happen to achieve the strategic outcomes our business seeks. So we don't want to state general good principles which are good practice but not something we should extend and encumber the architecture decision set with (everything we add to the architecture consumes attention of those who create and maintain it, those who need to understand and act in accordance with it, and those who govern it).

Which begs the question--how long-lived are architecture principles? As business strategy and architecture drivers change, we want to revisit the set of principles, looking to cull principles that no longer apply, adding principles that reflect the new direction. Once a principle is enculturated within the organization, we may continue to keep it in the architecture decision set if it is a point of uniqueness to our organization and we find that as we onboard new developers and architects (new hires or through acquisitions), the principle is important to helping bring them into our organization's (technical) culture (for technical principles) with its norms and principles guiding decisions and practice. 

So here's the template we advocate:

• principle name: catchy!
• principle statement: clear statement that will guide decisions addressed by the principle to be in accord with and achieve strategic intent/architecturally significant system outcomes
• rationale: what benefits we get from following the principle (motivating why we have to change what we do); provides traceability to strategy or system/architecture objective the principle will help us meet
• counter forces (aka counterarguments or alternatives considered): provides a place to say we recognize what factors weigh against the principle and what other approaches we might take (that other people in our environment would argue for) and why we shouldn't do that. One way to think about the counterargument/counter force, is that it illuminates implications/things that need to be done to ensure the principle is followed/viable in the social/business/technical context. It provides a place to say "in the face of dilemmas and tradeoffs and pressures we tend to do this, and this is how it hurts us" and "we could alternatively take this other approach, and this is how that would hurt us."
• implications: what we have to do to as a result of and to facilitate following the principle
• scope (optional, as relevant): the intended scope of impact of the principle (explicitly denoting decision scopes to which the principle does not apply, so that these don't have to go through the exception request process, assuming the principle is tended under the governance process).

I broadened counterarguments to counter forces to explicitly direct attention at any forces (including counterarguments or alternatives that others may try to use to displace the principle) that may impede our ability to follow the principle. These will give rise to implications, or things we need to do to ensure that the principle is technically viable and organizationally feasible. Other kinds of implications are the downstream consequences of the principle, issues we will have to take care of, etc.

3/8/11: Responding to a tweeted question about guiding principles for EA, I mentioned the Architecture Principles page (where examples of principles and other references are collected) on the Bredemeyer site, as well as our Principles for Architects page (you know, describing the Minimalist, With Teeth and Connect-the-Dots principles).  Of course, guiding principles for enterprise architects are more like the second, and less like the first. The minimalist principle drives our approach to principles that will be formally collected under the rubric of the enterprise architecture. What we call these things and how we treat them, is going to have something to do with whether they are going to be part of our architecture (formally), and hence under governance. In other words, do teams have to motivate (and even formally request an exception) their decisions when they run counter to the principle, or is it something they can treat as simply a guideline? If the latter, perhaps we'll just call it that -- a guideline.

That said, architecture principles are a mechanism to express values in terms of behavioral/decision guidance, and are an important way to shape culture. They are part of the "left hand" work of shaping and guiding culture so that the architect can use a lighter touch approach (see, for example, p16 of The Art of Change: Fractal and Emergent or here or here). I suppose there are a few guiding principles for architects contained in that right hand left hand image, but minimalist says go with the lightest touch approach that will create the strategic outcome. ;-)  

Principles are normative – they express how things should or ought to be, how to value them, which things are good or bad, which decisions or actions are right or wrong. It might be tempting to overdo our prescriptions here. Every principle we add to the architecture, consumes cycles -- creating and evolving the principle statement, understanding and following the principle, and governing the principle (otherwise they'll be ignored) all costs attention (see discussion/motivation in Principles for Architects). In other words, we can view Architecture Principles as a lever to help set and maintain direction/course, so long as we don’t get overzealous and wash out their impact by having so many we overload the attention space and cause them to be ignored.

If, by "architecture principles," we meant fundamental laws ("facts of nature underlying the working") of software or enterprise systems, the discussion and guidance would be a lot different!

A guiding principle is a rule of behavior that leads to good things; in architecture, we mean a specific approach that leads to good designs. For example, this statement contains a guiding principle: "Conceptual integrity can be achieved by uniform application of a limited number of design forms." p. 31 Bernard Witt, Terry Baker and Everett Merritt. Software Architecture and Design: Principles, Models and Methods. p. 9. Van Nostrand Reinhold, 1994

Clearly we are not saying that architects shouldn't collect, organize, disseminate and teach guiding principles/approaches that leads to good designs. The point is only to separate general education of the development teams from principles that are formally used to shape the direction and decision space.

I'd love to hear how you think about principles and where you agree or disagree with what I have proposed as the template and guidelines for its use.

* 1/14/12: I've moved two sentences from within the discussion (where they were quite buried), and added a third, to the beginning to provide orientation and placed them in italics. You will notice that this reframing draws on the discussion of 1/14/12 between Kris Meukens and Ernest Buise on Twitter. (Two statements were already there, with a word change here or there to sync up with the third sentence.) Anyway, if I improved on what I had done it is thanks to Kris and Ernest, and I think (hope!) placing an orienting statement at the beginning of the Principles post makes is more helpful!

Note: Strategy is fractal, so we mean strategy at the level of scope we're working at -- business strategy for enterprise architecture, product or service strategy for the related system architecture.
 

7/31/10 Software Visualization

The software visualization community seems to have focused on one meaning of visualization -- forming images of the design implicit in the code, etc. That is, there is a focus on the existing system, and making aspects/characteristics/dimensions of the system visible. So, for example, the structure of the system is rendered; a picture is formed. I think, however, that both the following meanings are useful: forming images of system as intended (imagined, designed) and forming images of the system as it is. Then we have visualization applied to design intent ("smoke") and design reflection ("mirrors"). The focus on the (static) code visualization problem, liberated the conception of software visualization from our standard for visual design expression (the UML and sysML). This has meant that there has been creative exploration of forms and metaphors useful for visualizing existing systems. The apparent desire to distinguish and demark the field of software visualization, with its side-effect of highlighting weaknesses in design expression/visualization, has this plus side, but we need to be alert to where one informs and is informed by the other, because ultimately we would like the evolution of the design expressed in code and actualized in the system to inform and be informed by the evolution of design intent. The software evolution we want, is that which is driven because our intentions evolve, rather than devolution that comes because we have less and less design traction and start to make more and more ad hoc changes to the code (to try to keep pace with evolving intent or goals/objectives/needs). If there is a divergence between the way we express design intent, and the forms and formats for expression/reflection of the design (structures, mechanisms and processes) inherent in the code and dynamic system behavior, then we have to create mechanisms to translate between the two. That's ok too, if we can tool the translation process, but it is more transparent, there is less to learn, etc., if the same expressions serve both the design thinking/improving and the exploration of the design of extant code and running software.

Visualization: What?

visualize [www.websters.com]

–verb (used without object)

1. to recall or form mental images or pictures.

–verb (used with object)

2. to make visual or visible.

3. to form a mental image of.

4. to make perceptible to the mind or imagination.

visualization or visualisation [www.websters.com]

— n

1. the act or an instance of visualizing

2. a technique involving focusing on positive mental images in order to achieve a particular goal

Visualization: Why?

• answer a question

• make decisions
  - support analysis and reasoning

• to explore and discover, encourage creativity
  - to look at things in a new way

• communicate information to others
  - make a point
  - tell a story

• inspire
  - part of our cultural heritage

• amplifies cognition/perception [Card, Schneiderman, MacKinlay, Readings in Information Visualization]

-- Source: Pat Hanrahan, Stanford CS448B: Visualization

Stanford CS448B Readings list

How visual models help:

• Increase understanding of complex systems

• Explore and compare design alternatives at a low cost

• Form a foundation for implementation (code generation, reverse engineering and round-trip engineering)

• Capture requirements precisely

• Communicate decisions unambiguously (using UML or sysML)

-- Source: Eclipse Concept: Visual Modeling

Tools

• Lumeta Network Visibility

• Great slideset on trees and graphs

Stanford Info Vis Resources

• Tamara Munzer, CPSC 533C: Information Visualization, Fall 2009-2010
• Pat Hanrahan, CS448B: Visualization
• Information Visualization Resources on the Web [last updated 2002, but still interesting]
• Jeff Heer: TimeNets,

Other Resources

• Ben Shneiderman's The Eyes Have It! presentation

7/31/10 Good Design and Code Value

Culturally (meaning in our techno-geek culture, not national/geo-centric cultures), we place emphasis and value on code. So much so, that we tend to endanger explicit, intentional, documented design. In the heat of the moment, turning out code rather than explicit design artifacts wins--and we keep turning up the heat!  Even in a "lean" kanban orientation that includes a requirements/business analysis stage, we have pressure to go from requirements to code. The kanban process in lean software development might be called cascades, though this wouldn't be "sexy" in view of the antipathy we've developed around waterfalls--instead of big drops, these are broken into many small drops that are repeated as the system is built out in small increments, so there is more communication between the specialty disciplines of the work stages as work "flows" between them. These mini-stages and the WIP pull orientation keep the heat turned up. (Others things too, but the effect of the heat is what I'm highlighting here.)

Now, I drew on the designer clothing analogy* earlier because it occurred to me that we need ways to express the value that is in good to great design (where the measure is in business terms, but including a valuation of structural integrity). Yes, the design is realized in code, and often the only design thinking that is happening in a transferable way (taking it outside the head of the thinker), is happening in the medium of code. Then the question is, are better designs created simply in the medium of code, or in other media and mediums (including code, but potentially in targeted prototypes)? And can we afford to invest in better designs -- indeed, can we afford not to? All the arguments that are massed along the lines of "we don't know enough" and "we don't know what we don't know" and so forth, argue for more exploration and experimentation--so long as much of it can be done more cheaply!

So, yeah, sure it becomes a management issue--do we resource experimentation or do we just resource (fund and staff) building code? After all, until we have running code the "goodness" of the design is a moot point, and increments of working code are the best vehicles for testing customer acceptance and adjusting based on that ultimate of tests, application in the real world. Right? Well, no. "Best" is context sensitive. If there is high uncertainty about the value model and/or the design, we can explore options and alternatives quickly and cheaply using paper mockups (including sketches and models), role play, performing thought experiments and making reasoned arguments, etc. Given the uncertainties, risks and challenges we face, design is about getting options on the table (divergent gathering of alternatives) and combining elements and ideas to form a convergent approach that will best achieve our desired outcomes (acknowledging the balance between where we seek to delight and where we will satisfice--recognizing that this too is a design space that we iterate on). So there is also a leadership issue, and a question of what we choose to advocate, and enculture. Yes, yes, I know all about pushing rocks uphill. And cutting code to do ad hoc in-situ design is a "letting rocks follow gravity" kind of approach.

If we want to get out from under the rule of the Kludge, to avoid the "big ball of mud" as dominant design, and create more modular, more evolvable, persistently mutable systems, we need to design for that--and keep designing for that!. If we want to create hub architectures that become the platform for flexible, evolving relationships, we need to design for that. Etc. We design to achieve desired outcomes, to direct our intellectual and team/community effort at making the system more the way we want it to be. Which means also deciding what that is, which is itself a design activity!

Now architecture is about the design of the whole, of the system--the design of the parts, yes, but so as to achieve the design goals, outcomes, objectives of the whole; to achieve fit of the system to its context and intended purpose; and hey, to dynamically, collaboratively find out what that intended purpose is, even! Architecture is about design across boundaries. The boundaries or joints within the system. Yes. But also across the boundaries of the system. And design across the contexts of use. And design to accommodate axes of change we have high confidence will factor as we evolve the system.

If you are discounting this post as ho hum Ruth at it again, you do us both a disservice. There are important additions to the common way that architecture is talked/written about in the above paragraphs--along with the same old drum beat. New nuances throw light not just on how we articulate and "sell" architecture, but also have implications for roles and responsibilities. For example, we see that in a fractal approach to system-of-systems design, there are overlapping roles/responsibilities at boundaries within the system and across systems, and the system architect collaborates with, but follows/is led by, the system-of-systems architect. And so on up and down the scopes of systems.

And we are saying that design has its own payoff in value that is greater for explicitly, intentionally scouting out value and challenge, articulating strategies for  addressing those, then creating concert among minds to figure out how to build something better than a purely add and adjust, reactive kind of approach would produce. The concert among minds part is why we need to document our designs, and evolve them (intentionally evolve the designs, but also reflect design decisions made in the code back into the design artifacts). To ensure design intent, including structural integrity (within the design envelope we negotiate with those investing in the system), we need to design and develop a shared conception of the system design--its goals, strategies, organizing structures and mechanisms.

So, yes, complex systems are that--complex--and complexity tends to be correlated with big, meaning a lot to grok. This means that visualizations of the system structure are important, and ways to navigate--to selectively reveal more detail--are important. That is where much of the work in code visualization has focused. But we also need to gain intellectual traction so that we can effectively engage more minds in creating a great system. And we need to have better ways to figure out where to focus these great minds and the work they collectively produce---ways to find the value model that will create differentiating business advantage for our organization.

All of this speaks to the need to design, and to leverage visual design at that. UML, yes! But informal sketches like Rich Pictures are an important design tool. We also like The Grove graphic facilitation templates and our derivatives and spin-offs (like Stakeholder Profiles). And where we are using the UML, at points we work very sketchily--specifically when we're simply exploring and probing, covering a lot of lateral ground as we discipline ourselves to think divergently and get options on the table. But as we converge on a chosen approach, we use selected UML models along with text to specify key decisions. In short: 

Good design enhances the value of the code. 

Now. And into the future.

And good design protects the value in the code.

Now. And into the future.

Because, YAGNI advocates notwithstanding, today's future slips so quickly into the past, and we have to be careful what we declare we won't need! It is a judgment call, not an absolute.  

And good design generally takes considered, collaborative work to produce. Considered--intentional, explicit, imaginative explorations, reasoning, testing, probing, trying, advocating and countering, ... Collaborative--drawing on and drawing in diverse other people with ideas, expertise, perspectives, ...

* I've seen the gap between revenue and assets and market cap used as an objective valuation of branding, and branding is increasingly related to design, rather than (only) advertizing spend. Well, I didn't think that is an adequate picture, but it gives another way of articulating the recognition that design has value.            

[Aside:  YAGNI arose as a discipline correction (correcting, for example, our technologist tendency to gold-plate); but overcorrecting is also detrimental.]

Ok, Daniel, do you want to ask me again why I journal? By unraveling that thought I got to Good design enhances the value of the code. And good design protects the value in the code. If you configure and reconfigure words, eventually some combinations fall out that you like! Call it epiphany. Eureka. Insight. Vanity. Whatever. :-)  I'm teasing myself. But framing is important, and while Dana Bredemeyer and Grady Booch seem to have an incredible knack for catchy turns of phrase that orient and inspire action, I have to work at finding them. Dana? Well, how about "good, right and successful" and "goodwill is the silver bullet"?

I know, what I landed on sounds an awful lot like "right product, built right" (which is so commonly used that I have no idea who to ascribe it to). Yet, to get the design of the product and the design of its guts more right, we have to do more design--where design is the practice of making things more the way we want them to be (Herbert Simon). That isn't the same as advocating BDUF, but rather agile architecting that precedes and accompanies agile development--informing and being informed by iterative and incremental development. So we embrace a combination of explicit, intentional design, and implicit, emergent design (in the medium of code) that we reflect on and may decide to refactor or evolve the design documents to reflect.