I also write at:

Blogroll

8/9/10 A Historical Note: Just Enough is Enough Already!

Just Enough Software Architecture. That is the title of George Fairbanks book, and it is a good one! You no doubt remember (if you followed the Fusion Newsletters I edited, and the Fusion website I was principal editor and writer for--back in the mid-90's) that one of the key differentiators of Team Fusion was that it was a just enough method (or JEM), a term we coined. Oh right, and Chapter 9 of The Handbook of Object Technology, Fusion 2.0: A Process for UML--that's the chapter by Derek Coleman, Todd Cotton and I--begins 'Fusion 2.0 provides an effective software development process and "just enough" method to manage project risks.' And we have long talked about just enough design upfront (JEDUF), contrasting that with BDUF. So, you see, I (and Charlie Alfred, who has, in key ways, led my thinking in this area) very much align with "just enough software architecture" and a risk-driven approach.

Charlie, of course, tends to simply say Enough Design Up Front, or EDUF rather an JEDUF. Now, I'm sure you remember Emerson's quip, but I'll repeat it in case you haven't had the pleasure of stumbling on it:

"Simplify, simplify."

That is applying a key principle of architecting to the statement of that principle of architecting. It is alternatively stated as Occam's Razor, though Emerson's (ostensible) version is the most terse!

Eb Rechtin, one of the founding father's of system architecting, and a proponent of heuristics in the art of architecting said:

"simplify, simplify, simplify"

He also said:

"communicate, communicate, communicate"

which I think illuminates his use of 3 "simplify"s!

So, just enough, or enough. Either way, it's a good idea. Hard, you may say, to execute on. But that is why experience is a value in architecting. You want some "can do" enthusiastic optimism, but it is also good to have that voice of experience illuminating the risks, challenges and uncertainties so that the design addresses value and challenge and risk. How we want things to be, after all, is very much about value, but value that isn't unraveled by structural flaws!

I have, so far, only dipped and dived around in Just Enough Software Architecture to get a sense of the coverage and George's approach to and thinking about architecture, but that has left me wanting to read further. 

8/10/10 A Visualization: Evolution of Pygmalion and Other Tales

This by way of a Codemap tweet:

• Telling Tales: The evolution of four stories

8/10/10 Lizards

This is Alistair Cockburn reading one of his poems: ☼The Hike 

8/11/10 Architect Certification

The Open Group:

• Level 1: Certified IT Architect – able to perform with assistance/supervision, with a wide range of appropriate skills, as a contributing architect

• Level 2: Master Certified IT Architect – able to perform independently and take responsibility for delivery of systems and solutions as lead architect

• Level 3: Distinguished Certified IT Architect – effects significant breadth and depth of impact on the business via one of three advanced career paths: Chief/Lead Architect, Enterprise Architect or IT Architect Profession Leader

-- The Open Group, IT Architect Certification Program

8/12/10 The State of EA Survey

"Stimulate your own thinking on EA strategies -- including EA frameworks, architectural models, certification, business architecture, and more -- when you take our short survey on Enterprise Architecture in 2010: http://www.keysurvey.com/survey/322064/b8ad/ . To thank you for your time, you'll receive a complimentary copy of the Cutter article, "Applying Enterprise Architecture: Seven Principles for Making It Work." In it, you'll explore what was needed to develop and mature an EA practice at a large U.S. utility."   -- email, Cutter Consortium, 8/12/10

8/12/10 Drawing on the Walls

My copy of Visual Meetings hasn't yet arrived, but the commentary is starting to flow, providing a glimpse of what is in store. This, by way of Anne Merkelson:

"Yes, not only are we moving towards using music to enliven meetings to create new ideas and new decisions, we are also returning to the wisdom our ancestors to use pictures to enhance the words. Fascinating that as life gets more complex, the more we return to our predecessor’s roots to engage the human spirit. What it takes to to break free new thinking to create exciting new futures, eh?"

-- Marci Segal, Cave drawings engage people in meetings – visual thinking, August 4, 2010

David Sibbet and The Grove introduced us to the value of graphical facilitation to make group work effective, productive and fun (rather than the negative patterns of entrenched, divisive behaviors that could come of bringing people with different perspectives and job turfs together). When I joined HP's Software Initiative (from the Software Technology Lab in HP Labs), I discovered that a "rite of passage" for that HP-internal consulting group was to take The Grove's graphical facilitation training. I confess I was as much a skeptic as most any other software engineer. And remained so for a good while, but observing my peers in the Software Initiative, and their work with development teams doing complex systems development (product platforms, teams distributed around the globe, etc.) in HP, I gained enough appreciation for the the value to tentatively venture into "drawing on the walls" to facilitate group work. Well, of course I had been drawing on the walls (and flip charts) in the Fusion, and then UML, modeling and design patterns work I was doing with software teams, but I hadn't ventured into vision and strategy facilitation with multi-functional participation. Now, anyone who has seen me do a Competitive Landscape Map (an outgrowth of Grove's Context Map) knows that my (messiest) drawings and handwriting in this journal are representative. (I'm no David Sibbet!) And yet most people get the value of that mechanism for structured brainstorming and collaboration despite my lack of skill. And I think, actually, in part because of it. They see me going out on a limb, and they enter into the spirit of the thing with openness and warmth. So, I guess I'm unabashedly drawing on people's intrinsic kindness and goodwill, but what we draw on gives something back too. Right? Positive expectation is a crucible for good things to happen.

In addition to drawing me into group graphical facilitation, David Sibbet is also responsible for drawing me into Second Life. Grady Booch might have, if it weren't for being able to punt and just watch him in SL on YouTube or InfoQ. :-)  Anyway, if you haven't visited The Grove on SL, I highly recommend it! It really instantiates a vision of what businesses can do in SL that helps further what they do in RL. 

8/12/10 Better Late Than Never

This by way of The Grove blog:  “The only thing obscene about it is the amount of time you are liable to spend there” : Chart Porn (http://chartporn.org/)

And this, by way of Chart Porn, is really, really funny: Some thoughts on Maslow's hierarchy. Lunchbreath totally gets dogs!  And robots!

8/14/10 Visual Meetings

My copy of David Sibbet's book (Visual Meetings) arrived. I recommend it most enthusiastically to architects--to anyone, really, who is trying to get big things done with and through people. I like to reframe design "meetings" to working team sessions, and visual modeling of various kinds is a mechanism to create a shared collaborative thought-space -- an externalization of the reasoning we might conduct in our heads but which, because we make it visible to others, becomes a forum for interaction, for clarifying assumptions, for making new connections, for asking new questions. "Group think" is bad, yet team thinking, when creative, collaborative, respectfully surfacing ideas, issues, questions, etc., is integral to innovation in an age where the creation of systems relies on diverse expertise, experience, perspectives, ...

Perhaps I make some smile at my "draw on the walls" because it seems naive or "retro" in a tooled world, but it is a recognition that comes out of much experience in a tooled world that our humanity is precious and vital to innovation, and it means we need to leverage the greatness that comes of human collaboration and from our ability to use tools to extend what we are capable of. Not one or the other, but both. We need to mature our designs, and as we do so, we need to mature our documentation of the design elements. And always, that is throughout, we need to keep track of our thinking--first sketchily and then more formally. First more in conversations with jotted notes and sketchy diagrams (and digital photos), but then through more crafted models and words. And then reflecting what we built in models of the code that we contemplate and reason about, to help us further mature the design as well as to simply tend the system as we grow it and apply it in new ways.

8/15/10 System Properties or Qualities (Quality Attributes in SEI lingo)

• Quality Attributes, Mario Barbacci, Mark Klein, Thomas Longstaff, Charles Weinstock, SEI Tech Report, 1995 [Introduces quality attributes and taxonomies.]
• Quality Attributes and Service-Oriented Architectures, Liam OBrien, Len Bass and Paulo Merson, SEI Tech Report, 2005 [Assesses SOA using key quality attributes as the assessment lens.]
• Utility trees - Hatching quality attributes, by Arnon Rotem-Gal-Oz

Mindmapping tools can be used to create such "utility trees." I suppose quality refinements with QAS or test cases at the root nodes aren't, strictly speaking, "utility trees" though they derive in form from utility trees.

I liked this use of a mindmap for navigating code smells, although the links are broken.

Qualities and Mechanisms

• Quality Attribute Design Primitives, Len Bass, Mark Klein, Felix Bachman, SEI Tech Report, 2000

8/17/10 Lessons in Grid Computing

Mark recommended this book at the last open enrollment Software Architecture Workshop:

• Lessons in Grid Computing: The System is a Mirror, by Stuart Robbins, 2006

Here are some words from the overview on Amazon:

"Packed with truer-than-life stories, stimulating characters, and unique IT analysis, Lessons in Grid Computing finally declares:
* Our systems will not "talk to each other" if our people are not talking to each other
* We must transform ourselves to the same degree that we want to transform our systems
* To correct problems in our information systems, we must first address the problems between the people that build and support them"

Sorry it took me a while to post this--it comes highly recommended by an architect I much admire; I had just misfiled the note with the workshop logistics stuff, and by chance came across it tonight.

I believe it was also Mark who pointed us to this excellent piece of our tribal history: Real Programmers Don't Use Pascal (1983). Sorry if I misattributed the reference.

8/18/10 Pattern Finding

This slide in Ryan Coleman's deck is eloquent:

Image Source: Ryan Coleman, Designing for Visual Efficiency

8/18/10 Quotes To Architect By

I stumbled on "10 Photography Quotes You Should Know" by way of Ryan Coleman (who is active in the Viz Think space), and especially like the first:

"You don’t take a photograph, you make it." - Ansel Adams

After I get done with To Lead, I'll take a cut at a list for system architects.

8/18/10 Visual Frameworks

• Set - Visual Frameworks, James Macanufo

8/18/10 Signs of the Times

Since I'm not journaling ;-) while I finish To Lead is to See, to Frame, to Draw... From time to time I see signs and later wish I'd taken a photo--like one in town which said "ONE WAY or another" (the last part being a graffiti add-on). Here are some signs for fun:

• ahead stop, xkcd
• the 8 most insanely obvious signs of all time, Huffington

8/19/10 Change: What the Red Queen Told Alice

"here is my comment to this motivating article:

This article makes me think of the book I just read, "The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition", on this topic of organizational change and innovation. I think that the author Steven Spear's insights from Toyota on how companies can develop the disciplined skill of innovation provide helpful guidance on how any company can continuously improve towards excellence in any market condition.

My summary of key ideas in Steve's book The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition, and from his webinars on this topic:

• Some organisations are capable of achieving and sustaining exceptional levels of performance that gives them and helps them continue to maintain a significant competitive advantage over their peers

• Exceptional performance requires the capacity to generate and sustain high-speed, broad-based, non-stop, improvement and innovation

• Complex systems (which engage many people across different systems and functions, in non-linear relationships) hinder exceptional performance; these complex systems are impossible to design right from the start, but can be perfected through relentless, continuous improvement and innovation (discovery)

• Innovation is not the “kiss of inspiration” on the brow of the genius; rather, improvement and innovation are rooted in a disciplined set of skills (which can be learned, practiced, applied, and improved) around the basic science of designing, operating, and improving complex systems of work

• Senior leaders serve a critical role in the design and improvement of systems, and are responsible for cultivating these skills in their people

• The four capacities of high-velocity organisations:

1. Specifying design to capture existing knowledge and building in tests to reveal problems
2. Swarming and solving problems to build new knowledge
3. Sharing new knowledge throughout the organisation
4. Leading by developing Capabilities 1, 2, and 3"

-- Andrew Parris, comment on The Art of Change: Fractal and Emergent sent to Cutter, and copied to Dana and me, (personal email), 8/19/10

8/19/10 Workshop Scheduling

We are working on the open enrollment schedule for the remainder of 2010. We will fit in an EA workshop, and at least one Software Architecture Workshop in the US (in addition to the two in Europe in September). Ping me () if you want to influence where we hold these. We looked at Washington DC, but the two weeks I'm available, there are big conferences going on in DC making it hard to find a suitable venue. So, for the SAW we're looking at Boston and/or Houston at this point.

The bigger question is around the Architectural Leadership Workshop. We might float one and see if it fills sufficiently. Oh, right, we do run a good number of the Leadership workshops internally every year, but open enrollment is a tougher proposition since we distinctly avoid salesy kinds of activities and rely only on a discrete pointer on our website and word of mouth. In case you hadn't noticed, this is not the best of years for "discretionary" budget items like training, especially soft skills training. It is ironic, because this is exactly when compelling leadership is needed. I mean, who doesn't need architectural leadership. Yes, the title is a play on words -- competitive leadership through architecture, and architects as great leaders.

Software Architecture Workshops (to be taught by Dana Bredemeyer in English):

• Düsseldorf, Germany, September 13-16, 2010 (hosted by CodeCentric)

• Eindhoven, The Netherlands, October 4-7, 2010 (hosted by the ESI)

8/19/10 Environmental Footprint

Here are some infographics that carry a double-punch (making our impact visual, and making the point that visual has a powerful impact):

• tracking the oil spill in the Gulf, New York Times [these folk really show how visual reporting should be done, and it illustrates what is possible in the "we need to understand the meaning in the data" (BI)]
• Climate change -- skeptics versus scientific consensus, The Visual Miscellaneum, David McCandless, informationisbeautiful.net

8/23/10 Innovation and Leadership

I hope that you found The Art of Change: Fractal and Emergent useful, both personally and as a way to open discussions about the relationship of strategy and architecture in the spheres where you (would like to) have (more) influence. The point, given the fractal metaphor, being that this discussion is just as relevant at the application or product level as it is at the enterprise or product family level. And if Part One: Fractal and Emergent leaves you eager for Part Two: To Lead, remember that we like to involve a spectrum of our audience in the review stages, so that we can improve the report given different perspectives, questions, and suggestions. Part Two is about innovation, persuasion and influence, collaboration, etc.

Journaling in January, I wrote:

...  but especially to architects who lead--because taking on leadership is taking on meaning-making for a chunk of peoples' work-lives and that is a big deal! We don't have to take our team to Australia and fabricate urgency--it is in each of us already! It just has to find a target, and that is what the leader does--the leader crafts a compelling and urgent message: this is worthwhile, this is why, this is how soon, this is how it will be great. To lead is to see, to frame, to draw. To lead is not to drive. Rather it is to enroll, inspire, invite, empower, so the team is intrinsically driven by being involved in something meaningful and urgent. To lead is to demand, but not to command--to align high aspirations that demand unflagging commitment to giving of one's best and holding peers to a design aesthetic while getting the job done.    

So those are the two paragraphs that inspired the form of The Art of Change: To Lead is to See, to Frame, to Draw (which became too long to be one Executive Report, and got chunked into two). When I wrote that, I had sections of the report written, but I was looking for a way to organize the material. And there it was.

I went back to Kent Beck's One Team post -- I admire the humility of sharing that personal journey with its growing awareness, and I wonder if Kent would get value from Getting Past ‘But’? It is interesting that we have been learning from the XP/Agile/Lean community (and see ourselves part thereof), while it has been embracing more of what we have long espoused, as scaling issues are faced and braced, and design becomes ever more necessary given sophistication in expectation and compounding complexity.

Anyway, from there,  I went to Steve Blank and from there to Ash Maurya's site and was reading around his blog--I like it! This post, for example, is a great read: There is an "I" in Vision. And this line is so well put:

"The challenge isn’t building out a solution but validating that you have a problem worth solving in the first place." -- Ash Maurya

Of course, we build and iterate on a solution to find out if we have a problem worth solving, but if we can fine-tune our hypotheses about the problem before we build out a solution, so much the better. Yes, it strikes a Getting Past ‘But’ chord. Smile.

Hopefully one of the take-aways from The Art of Change is that we need to think of the strategy-architecture tandem fractally, and one of the off-shoots of that is taking on more responsibility for nurturing a synergistic business-technology strategy relationship at our level of scope. That doesn't mean trying to wrest control from the management tree! Rather, it means understanding the business from multiple points of view, not just from the point of view of the "guts" of the systems that the business is intertwined with, and stacked on top of. So hopefully you will find posts like this useful: "How I Document my Business Model Hypothesis" -- and then you can try it out on your product (or enterprise).

Another complementary and crucial view is the "identity--value propositions--capabilities" strategy framework. :-)  (Remember, value propositions include value propositions to shareholder/owners, to customers and channel, to employees and other value partners.) 

Oh, I should perhaps add that the problem-solution distinction that Ash makes, could usefully be viewed as a way to find the compelling, distinctive value proposition, and so is subsumed in the statement of the UVP (unique value prop).

In our framework, we distinguish key partners (and others in the value network) in order to determine what value they contribute to our core value propositions, and what value we need to offer value partners, to make it all work, systemically. It is taking an ecosystem frame, and thinking about the flows of value. This is useful to do at different granularities. For example, if you're providing common services to several apps teams, you want to think about the value flows. In that case, your primary "customers" are internal teams, and they are as make-or-break as their customers.

At any rate, I need to draw out the relationships between our Visual Strategy Framework and the Business Model Canvas. Just as with VAP and 4+1, there is a mapping and the approaches are complementary.

8/25/10 Architectural Mechanisms

When we study animals, including humans, a distinction is made between anatomy (the consideration of the structure of living things, wikipedia) and physiology (the "science of the mechanical, physical, and biochemical functions of animals/humans in good health, their organs, and the cells of which they are composed", wikipedia).  For example, if we think of ambulation, we think of the interaction between various components, and we can narrow it down to a focus on the various joints and how those work, and how various components interact in coherent purposive mechanisms, and mechanisms in combination collaborate or interact to achieve ambulation. We can think of the knee in terms of it's purpose or goals, anatomy (the parts) and physiology (the function) -- that is, in terms of the knee as a mechanism.

That "what are the structures" versus "how it works" distinction is useful to make in architecture. The point that we emphasize in the Visual Architecting Process (VAP), is that we need to think about both the structures and the "how it works," holding both in creative suspension and iterating between various (as useful to us) views of structure and behavior. For the most part, design patterns, to me, are usefully documented descriptions of tried-and-true mechanism designs. So we're working with experience and patterns, with capabilities and responsibilities and structures and relationships, and how these structures interact to deliver capabilities with sought properties within design tolerances.

8/25/10 Requirements "Churn"

We often point to requirements churn as a major source of issues, even failure, in software. But isn't this an artifact of our aberrant notions about "requirements"? We take desires, and goals, and constraints, and hopes, and frustrations, and so forth from (maybe) "representative" stakeholders, and think we have "captured" a set of requirements. We may even shadow users, interview them, have them keep journals, model their business process, and so forth. But what we form are hypotheses and best guesses based on gut feel and impressions and suggestions and loudest voices and conversations on the golf course and at the coffee machine--not just one, but many, interacting best guesses and assertions (founded on who knows what assumptions). If we just recognize that these are hypotheses, in a good case, but just barely articulated hunches in the average case, then we see that they are highly subjective, accidental, speculative, mutable, emergent and interacting, conflicting, subject to tradeoffs that may, rats, be cued up subliminally, etc. Hence, we need to be more explicit about testing various alternative best guesses as quickly and cheaply as possible, moving around the space and tuning up our sense of what will be an exciting product for a big enough market to make good business sense. Then we orient our whole process towards designing the concept and its interactions with the environment--we design its purpose and its fit to purpose; we design (with varying degrees of freedom depending on the context) its fit to context somewhat by redesigning its context, etc. That is, design is an act of creation--of problem finding and solving--from the first seed of an idea through stages of maturation and evolution, and fresh upsets in expectation generating new opportunities to find and solve problems.

In other words, we have tended to take something that is inherently organic and messy, even chaotic, and act as though it is mechanistic and deterministic. The properties of complex systems emerge from interactions--interactions with the context, and interactions among the parts. These aren't entirely knowable in advance. Worse, though--expectations and desires also emerge! This makes the development of new systems inherently wicked. Moreover, the evolution of complex systems tends to be a wicked set of problems, because complexity means we don't have a complete handle on the system even before we attempt to evolve it.

So, yes, we do need to make development as predictable and well-organized as we can, without thwarting creativity. But we also need to have different expectations and measures for production lines than we have for system development.

And yes, we do need to state our goals, and become more and more clear about acceptable ranges of tolerance for system properties and refine and elaborate the core functionality, and all the good stuff of requirements definition. But we could stand to use a more innovation-age, less industrial-age, approach to requirements and our definition of churn and failure. We need to stimulate and embrace churn (or ambiguity and uncertainty) early on, fail fast, cheap and often, early on, so that we can find the differentiating value propositions (for business stakeholders, for customers, and for other key players in the value network) that have a good shot at making the system a big success. If we fail to do this, we get requirements churn late in the process, and that is costly and costly failures are what we need to avoid! 

Unless the churn is coming from a new perturbation in the market, in which case we have to discover what new problems and opportunities and threats are presented to us. And so it goes. Iteratively. As we evolve the users concept of the system, its place in various contexts of use, and our concept of how to build and evolve it.

Well, of course there are different degrees of uncertainty, even for different parts of the system, just as there are different degrees of complexity, even for different parts of the system, and varying degrees of freedom. So our process needs to be flexible enough to accommodate to where the uncertainties and challenges are.

While we recognize that there will be emergent desires and clarification of expectations, and other kinds of tricksyness, we don't throw up our hands in despair at the "great buzzing confusion." Well, not if our process allows us to create a mirage of order behind which we can proceed apace to create order! :-) Which is to say, we don't do away with the hunches; we just get better at figuring out which to test, and applying discipline to looking beyond first ideas, and testing more of them. That is the purpose of the decision model, and the architecture dashboard, for it allows us to iterate and refine, reify and redesign, while creating a moving envelope of decisions (and, increasingly, running code) that we have traction on.

Somewhere between "run with the first idea and tweak from there" and "a paralysis of seeking out (more and more) options," there is a better way. A divergent-convergent iterative process that says "blink is good stuff, but beware." Intuition and hunches can speed us along -- a perilous path. It takes gumption to speed into the unknown, and it takes gumption to peer enough into the unknown to figure out if there be dragons or value trees therein.

Of course, context factors. If our business intent is simply to replicate what a competitor has done, we have fewer degrees of freedom as the product and its interaction model are already designed for us. Then we're just focusing on the guts. But competing this way is a brutal cost-based battle. We make the case for involving architects in fast exploration to find and progressively clarify differentiating value propositions. The architecture team addresses architecturally significant technical challenges. These challenges are introduced by "requirements" which are shaped in conversations. It makes sense to have the right constituencies shaping and participating in those conversations. Not all technology push. Not all technology push-back. But a balance of technology and market and business sense and sensibility, experience, know-how and what and why and where and when. Etc. Yes, the stuff of Getting Past ‘But’. It's still art and engineering, guesswork and experimental probing, luck and diligence. But until we look the chaos dragon in the face, we have no idea what we're dealing with. We can pretend its merely a feral cat, and sometimes the scale is small enough that works.

The hard stuff. What to draw within scope, what not. How the system works. How it stands up to the stresses and strains (that will be) placed on it. Design. Intentionally making things more the way we want them to be (Herbert Simon).   

With a clear decision model, we can "fake" a deliberate progressive elaboration and refinement that ultimately yields a specification or blueprint for the system. And we can map a messy process to this decision model -- a process that is not all top-down or all bottom up, but which balances exploration and navigation at multiple levels, to design the target, create strategies (business and technical), and build the system and adapt its context. The decision model gives us a clear place to look for and put decisions, but doesn't tell us what order to make the decisions in. It also strongly suggests which kinds of decisions we should draft, and then mature first -- architectural strategy (or Meta-Architecture) before Conceptual, that before Logical, etc. But the process encourages us to navigate by uncertainty, value, challenge and risk, not some precast sequence that is ignorant of our context with its unique goals, uncertainties and challenges. For the newbie architect who is uncertain about sequence, the decision model and process does lay down a path for gaining confidence.

Ultimately, I think the process looks something like this. Just kidding! Garr!

"I think more than I want to think" -- from lyrics to Lilac Wine. ☼This rendition of Lilac Wine♫ (by way of Scott McLoud) is gorgeous. (I also love ☼Jeff Buckley's version♫. He had such a voice, and made such sensitive use of it!)

8/26/10 Software Architecture Workshop

Ok, we have added an open enrollment Software Architecture Workshop to the schedule:

-- Boston, MA, November 8-11, 2010 (enroll now to qualify for the early enrollment discount)

We have run workshops at The Endicott House before, and it is really a lovely venue. Not that the venue is a decision factor, of course. Well, actually, it is for us, because it carries a high penalty if we don't reach critical mass (in this double-dip feary economy). So, please help us get the word out! :-)

I'm updating our process chart for the workshop and a conference presentation Dana is giving in Germany in a few weeks.

8/28/10 The Jumper Colon Yet!

A new use for the colon: to springboard sentences! Colonoscopy: It's time to check your colons is an entertaining read, especially in the light of my introspections around my -- um -- enthusiastic use of em dashes. You sensed it, and it runs deep: the hyper-connected texting, twittering, electronic media viraling age impacts the very syntax of our communication.

But of course! The spoken word is rich and expressive. Messy. And yet we convey by cue in addition to the words, so we try to mimic that. Choppy, short sentences: thought speed. Hesitation... incomplete...  What not.

Actually, I got dinged in English lit papers decades ago for my over-use of em dashes. In the same breath, though, I was told my writing was racy, I was given top grades and awarded honors. Not exactly the most consistent message.

8/28/10 Re"Tweet"

If you were following my visualization tweet stream, you'd see a pointer to a great presentation on Visualization in Software Product Lines by Thiago Fernandes of the RISE (Reuse in Software Engineering) project in Brazil.

Some people seem to think that "reuse is dead." Reuse will never be dead. Our antibodies towards the word may be ferocious, and we may prefer to say "use" or some new word with which to make the practice of building with existing stuff more sexy. We keep raising the platform of software development, moving more into "middleware" and frameworks, which we "use" (or reuse). And when we are creating product (or service) variations, we are going to clone and grow (sloppy reuse) or more systematically reuse (or use existing) software elements. 

This presentation also deals with visualization in software product lines: Virtual Separation of Concerns, by Christian Kästner

I also looked through several presentations by Michele Lanza and PhD students including Richard Wettel (The Visual Terminator, Of Code and Change: Beautiful Software, Visual Exploration of Large-Scale System Evolution, Visually Localizing Design Problems with Disharmony Maps, Visual Software Analysis, Software Evolution, etc.). There is overlap among these presentations, but even that is interesting because it provides an interesting view of the evolution of their research as well as the evolution of the framing or pitch for software visualization. I love this slide from Michele Lanza's presentation titled Seeing Software:

Now, it'd be cool to see, instead of just connections, the dynamic "flight path" unfolding (video). And it could get still prettier (and revealing) if lines were color-coded to show package dependencies (back to static structure), so you'd see breaches in layering rules, and potential for circular dependencies. Etc. As for city evolution, it'd be neat to see that applied across a product line. Etc. Take any one idea, and other ideas hang like fruit from it. Oh yes,

"nullius in verba" is Latin for "Take nobody's word for it"

As information visualization goes, Justin Donaldson and Paul Lamere's Using Visualization for Music Discovery slideset has lots of interesting, even stunning, examples, and their discussion of visualization has much that applies to any visualization space (some of it is taken from Colin Ware's Visual Thinking For Design book).  This visual map of visualization approaches in music is neat:

Source: Using Visualizations for Music Discovery, by Justin Donaldson and Paul Lamere

I know, I didn't embed the presentation -- I simply wanted to direct attention at a specific slide, keeping the slide number reference visible so that I can go back to it. By all means look through all 266 slides, as it is quite interesting to see what creative work is being done in information visualization applied to music discovery. :-)  

If there are visualizations that you are using to help you get/keep a handle on your software (code base), please let me know what you're using and how you find it valuable. I don't have access to every IDE, for example, and more visualizations are being integrated. 

8/28/10 Motivated!

Before closing down for the night, I stopped by Jeff Atwoods blog and, on his insistence (if I didn't follow well, what kind of example would I be setting?), I watched Dan Pink and RSA Animate's ☼Drive: The Surprising Truth About What Motivates Us. It is really well done, and makes an important point! Since architects are setting the team context that allows for empowerment and self-organizing, self-directed work to take place, this is a useful, and fun, use of ~11 minutes. It also motivates the involvement of people in the creation of the meaning and purpose of their work. And, again, it is a great visualization.

8/29: So I stood -- I was closing down, remember -- sucked by the youtube sidebar into watching "Smile or Die" and again the visualization was great, although Ehrenreich seemed to be playing for popularity in these upset times, and the logic was inconsistent/flawed/sensationalist. But the visualization is superb!

The use of visual metaphor in the drawings is worth attention all by itself. Remember, it is very useful to develop a toolkit of visual icons that you can practice sketching and do on the fly to spice up what you are saying, so that you show with pictures not only words. But the visual metaphors imply words, so carry a package of meaning. Blah, blah rhetoric. Advice you didn't ask for. Rats! Oh right. Advice to myself. Alright then, I can live with that!

Ok, I'm psyched. Let me at those sketches.

Or not.

Motivation is such a tricksy thing! Well, I love lunchbreath's Maslow's Hierarchy as Scorecard cartoon sequence.  Let me just say, I'm with the dog. 

Oh, the dog!  Gotta run!

8/29/10 Sketches

Here are some sketches (from early 2009) contrasting a start-up with a "mature" organization. I apparently had decided they weren't fit for public display. Silly me!

The next image in that set is the architect who functions despite the dysfunctional context, by ignoring the hierarchy with its communication gates.

Apparently I either hated the sketched and didn't finish it for that reason, or the architect was dis-armed... Which leads to...

Such an architect is vulnerable to being whack-a-moled:

Yes, I've used the last of those before. Actually, it was from a different sketch set, but it completes the vignette. :-)

Except. Here's another that belongs:

Yep. Kick "but." Just do it. The talk thing. The draw people in thing. The do thing.

Ok, before you think that narcissism made off with my appropriateness-meter, please bear in mind that this is a very quiet backwaters place where I trace some of my exploration and thinking. And if I don't use those sketches, and the story they tell, they will be lost in the accumulating stack of sketched notebooks.

8/31/10: Oh right, that's kick "but" not "butt," or alternatively put: 'kick the "but" habit.' Organizational politics/dynamics, leadership, persuasion and influence, all have a bearing. So, To Lead is to See, to Frame, to Draw has its application in turning around situations that may otherwise be fraught with gators (at the gates) and resistors.  While you wait for To Lead to be published, you may like to read Getting Past ‘But’ or offer to be a reviewer for To Lead.  For The Art of Change: Fractal and Emergent, no-one responded to my plea for volunteers so I tagged folk and all but two (it was a crazy-busy time for them) stepped up to the plate and provided really helpful suggestions for improvements, as well as really encouraging positive words. Most of those reviewers have already volunteered to review Part Two, but I'd like to spread the pain around. ;-) Alternately put, it would be super awesomely encouraging if someone said, "hey, I loved Part One and don't want to wait out your whole review-edit cycle to get engaged with the "how to" of Part Two. Ah well.

8/29/10 The Art of Small Talk

(Dana relayed:) Bucky Fuller said "Ownership is onerous."  When I lift my head from work and look the accumulation chaos dragon in the face, I so get that!

As for pithy statements: there is a challenge on the CAEAP LinkedIn group to express the purpose of EA in 160 characters. This SMS-chunked challenge has bounced around on Twitter, etc., so I've seen various stabs at a concise statement of what EA is. Anyway, given the terminology elucidated in The Art of Change, I took a swing at it:

Leading the fractal translation of business intent into business capabilities, and rationalizing emergent capabilities to improve design integrity.

It's not entirely satisfactory, even as a synopsis of The Art of Change: Fractal and Emergent, but I think we need to express that combination of top-down and bottom-up that we go after with "fractal and emergent."  EA, like (top-level) business strategy, deals with the "umbrella over all umbrellas" enterprise scope, but it is not all about driving purposive action but also about reflecting on and aligning and improving based on what is done and learned by those empowered to act and react responsively to opportunity and challenge at more narrow decision scopes.

Is that an important view, and does The Art of Change articulate the view, and its importance, in a compelling way? If you think not, that was rhetorical. Motivation is such a tricksy thing! E. T. C.  

8/30/10 Shattered Dreams

Dana stopped in to get bread at the local bakery, and there was a taster basket of "dream bar" bits on the counter. He tried one and the person at the cash register said "They're shattered dreams." Humor is all around us!  I had to do a visual, because it so fits the tenor of our times:

Must  . improve . sketching . and . handwriting . skills . Must . improve .  ... Or not.

Ryan can draw perspective better than I, but he and I both draw people as stick figures. Still, mine are boxier. Nah nah.

(Nah nah? Oh, I do miss Darth-Don. Wicked suit!)

8/31/10 Procrastination

I love the procrastination sequence on phdcomics (untitled procrastination, Your "To Do" List, untitled Just say "No"). Why am I looking at phdcomics? I'm working on that visualization presentation, really I am. Right now it is: visualization and quality. Glancing through Tom Zimmerman's presentation (I love the cover slide!) I saw this cartoon: strip 1 and strip 2. Ok, that is pretty much how I write those Cutter papers (wink), so I went to the source (I hadn't stopped by phdcomics in a long time; I really only troll cartoon sites on occasion, all link "Easter egg" evidence to the contrary, of course) and yep, stumbled on the procrastination sequence which is ... pretty much where I'm at with the Cutter paper. Well, there's the small matter of the "day job," working with Dana on his conference presentation and ... well clients would (emphatically) rather I didn't say.          

Back to visualizing bugs with me!

8/31/10 Visualization

I came across Stanford's Spatial History Project and these lines from their introduction to their Visualization Gallery struck a chord:

"Visualization of historical data in time and space illuminates patterns of movement and transformation in the past. We are experimenting with visualization as a tool to develop new arguments (and new questions) about historical processes and understandings of major historical events."  -- Spatial History Project, Stanford

A chord? Well, isn't that a neat way of putting it? We use software visualization to understand the system, but also to help us ask new questions about the system! New questions, new lines of inquiry, new tentative reasoning, are so key to developing new insights. And new insights are neat 'cos they produce a eureka flush in the brain and they lead to, like, cleaner, simpler systems... (kid-interrupted night last night; my sleep-deprived brain is on E)

Ta Ta August. It's been fun. :-)