You've reached my architects architecting architecture journal. This is where I keep track of some of the places I explore, things I read, thoughts I don't want to lose, and ideas I want to nudge around until insights fall out. I've struggled with the advisability of doing this "thinking out loud" in public, and I "put a lid" on this journal (pulled it out of general public view). Then I realized how much I'd miss my Google memory crutch, so allowed Google back in (leaving a trail of link crumbs for Google's very thorough trawler to follow). That meant that while my lid shut out friends who've graced me with their company on this exploration, Google was letting arbitrary others still get in. So, I pulled the lid off. Pretty much. Well, if you missed me, you can catch up on my March and April scouting and musing.

Photo right: Nature's composition: wildflowers and weeds... something like my journal?

5/2/09 Complexity

Grady Booch characterized the following as the architecture "fundamentals that never go out of style":

• Maintain a good Separation of Concerns.

• Craft crisp and resilient Abstractions.

• Create a balanced distribution of Responsibilities.

• Strive to Simplify

The exhortation to simplify is important. And at the same time, look at a flower. It is at once simple, and complex! Many of it's mechanisms can be reduced to quite simple terms, and yet when you look at the detail of it's structure there is so much there! Simple. And complex. That is the art and the engineering genius we strive for--to create systems that are at once simple and complex.  

The elegance in the "design" of a flower comes from its fine fit to purpose, and its marvelous beauty--balance, symmetry, color; none of it squandered or gratuitous. All fitting within the purpose of the plant, within the ecosystem in which it is adapted to play its part. 

Booch's fundamentals are very much about harnessing complexity. Stripping away the unnecessary, yes. But also by finding the natural interstices and designing mechanisms that cleanly, with elegant simplicity, address purpose and cross-cutting concerns. I noted that we can use the mnemonic SCARS for these fundamentals--appropriate since experience informs our endeavors to create systems that, taken as a mass of details, are enormously complex, but which can be viewed in terms of more simple structures and mechanisms.

"The ability to simplify means to eliminate the unnecessary so that the necessary may speak" -- Hans Hofman

"By three methods we may learn wisdom: first, by reflection, which is the noblest; second, by imitation, which is easiest; and third by experience, which is the bitterest."  -- Confucius

"Good judgment comes from experience, and experience comes from bad judgment." Barry LePatner

"If you're not prepared to be wrong, you'll never come up with anything original."

-- Sir Ken Robinson, Do schools kill creativity? Ted talk filmed 2/2006

I know, back in March I said you could expect less in the way of flowers, but it has been such a verdant Spring and the digital camera revolution--in good part thanks to software--has opened up a whole new way of appreciating the detail in flowers (without breaking the bank on pro-caliber macro lenses)!

5/3/09 Hammered Truth

Dana mentioned a phrase that struck him reading The Floating Island to the kids a few weeks back. In the story, Ven's father told him to speak only the "hammered truth" and the king lighted at this and appointed Ven to bring him the "hammered truth" from his travels around the world.

Isn't that great? There's the truth, and there's the 'hammered truth--facts that are not varnished or hidden, but shaped straight, like steel that has been hammered... "Tell people the hammered truth and it will ring like steel against an anvil."'

The truth that has taken the pounding of time and experience. The essential truth. The consultant, and the architect as consultant, needs to find that truth when we are called on to speak truth to power. Which is not the same as using the truth to hammer our point home! The truth needs to be handled with dexterity, even delicately, to ring clearly.

5/9/09 Nice Words from Around the World

I don't have even a reading knowledge of Portuguese, but from Google's translate feature I have a rough idea that Marco Aurélio's post titled Blog da Ruth Malan - A Trace in the Sand is kind--thanks Marco. It is good to see (mostly by inference) the good work you're involved in, building the software architect community in Brazil. 

I do have a barely serviceable reading knowledge of Dutch, and G.J. Timmerman has a good summary and introduction to our "What It Takes to be Great" paper and architect competency framework. I do rather like "inspiring" being used as an adjective related to our work, since I explicitly set out to inspire --and enable, of course.

That's the framework we use for what we do in our workshops and in our writing: inspire and enable. It is also what I believe architects need to do. Even if you have formal authority, it is more effective to motivate and enable the team to create a great system: effort required? effort inspired. And? enabled, of course. 

5/9/09 Recital Season

We're approaching the end of the school year, so this is school play and recital season, and we've been kept busy with piano, ballet, and recorder recitals, class plays, Spanish plays, and on, and on. It's fun though, and "Weezie" Smith's recorder students (of all ages) have a great program.

Weezie Smith is a consummate teacher--she is demanding but she helps her students reach for the best in themselves by inspiring and encouraging them. Their ballet teacher, Doricha Sales, is likewise demanding and no-nonsense, but she is always talking about the bigger context of a specific learning point, and helping the children envision themselves as dancers, inspiring them. And me!

Inspire and enable. 

5/9/09 Ban Powerpoint?

Of course not. But...

McNealy famously declared to the San Jose Mercury, 3 August 1997: "We had 12.9 gigabytes of PowerPoint slides on our network. And I thought, 'What a huge waste of corporate productivity'. So we banned it. And we've had three unbelievable record-breaking fiscal quarters since. Now I would argue that every company in the world, if it would just ban PowerPoint, would see its earnings skyrocket. Employees would stand around going: 'What do I do? Guess I've got to go to work'." Powerpoint: A Pig through the Python, Richard Hillesley, 2007

And Tufte famously headed a Wired article: 

"Power corrupts. PowerPoint corrupts absolutely" - Edward Tufte

Don Norman responded to Tufte In Defense of Powerpoint. But the point, of course, is that when conversation is needed, PowerPoint may not be a good tool:

'...Oftentimes, PowerPoint creates an obstacle to an honest, shirtsleeve conversation. While PowerPoint didn't invent one-way communication, it certainly perfected it.

Lou Gerstner's remarkable turnaround of IBM from near-collapse began with a briefing he asked for on the state of the mainframe business that accounted for more than 90 percent of the company's profits, which were sinking fast. Gerstner describes this critical meeting in his book "Who Says Elephants Can't Dance" as follows:

"At the time, the standard format of any important IBM meeting was a presentation using overhead projectors and graphics on transparencies that IBMers called—and no one remembers why—"foils." Nick was on his second foil when I stepped to the table and, as politely as I could in front of his team, switched off the projector. After a long moment of awkward silence, I simply said, "Let's just talk about your business." I mention this episode because it had an unintended, but terribly powerful ripple effect."'

PowerPoint: Boon or Bane? August 01, 2007 By Abhay Padgaonka

Watching the "talking at" tendency that using PowerPoint as a prop promotes, David Clarke also banned PowerPoint:

"As CIO for a global company a few years back, I actually banned PowerPoint presentations in my team for a while. ... The problem was that our attention span had become so limited that our level of conversation had degenerated to this bullet point way of talking and thinking. We were presenting to each other, not talking with each other. We didn’t know how to engage people in other ways, so we took the few minutes we got and gave them the Reader’s Digest version of the idea we wanted to convey."

Banning PowerPoint Reveals Flawed Communication, By David S. Clarke, November 15, 2001

5/11/09: PowerPoint is not the issue, really. It is comes up, because it is the de facto tool used to prepare presentations, and the issue is using one-way presentation when conversation and collaboration are needed. It's not just the "bullet points," it is the style of having the "podium" and managing attention to a preset agenda dictated by the slideset. In short, it turns meetings into lectures. Again, this is not Powerpoint, per se, but it is the mode we just fall into where we use a tool (Powerpoint, or our UML/round-trip engineering tool) and let that drive attention to center stage to the person with the mouse/clicker, when "people and interactions" need to be front and center.

When we want to communicate that we are fluid about our ideas--yes, we've done homework, but we're still in an expansive (divergent in the sense of gathering ideas), input-seeking mode--then drawing and capturing brainstorm ideas on a whiteboard or paper is a great medium. Yes, the facilitator still has influence over the flow of the agenda, but we don't get the same domination of the attention space as one typically gets with a prepared Powerpoint (or other) presentation. The message that is communicated is "we're open to input and open to shaping the flow of conversation around the audience concerns, goals and input."

A few points about mechanics:

• if the meeting room walls are short on white-board space, be prepared with extra sheets of paper or flip chart pads and painter's tape, and make sure that all work done in the meeting is visible at all times by taping up the paper as each sheet is completed. That way, you don't have to erase work to make room for more work.

• have a digital camera at hand and take pictures of the work--even if there is the intent to transcribe from whiteboard and/or paper to electronic form, still take digital pictures so you have a meeting record to refer back to.

• if you have designs, facts and figures, etc. to share as a backup to discussion, a (draft) white paper may be a good vehicle.

See also:

• Drawing on the Walls--It's not just for kids!
• Visual Modeling

Realizing that I'm on a "visual kick," Daniel Stroe sent me this link: Doodling may help memory recall.

We have long known the value of keeping the hands busy with something that doesn't require mental focus, to free the mind to pay attention. That is why we use Koosh balls in workshops! I suppose we could just ask people to doodle! Still, the Koosh balls also help people when they're presenting their team's work to the larger group. Keeping their hands busy with the ball, seems to allow even shy people to be less self-conscious. It is funny, but when I tell people what the Koosh are for, fewer seem to fiddle with theirs. You'd think it would be the other way round! Watching how people deal with the tag, I've made it the first exercise of the workshop to remove it. It gets people fiddling, and gives me the opportunity to quip that it is emblematic of the evolution of man--some brute force it, some use a tool, and some apply conceptual modeling and "reverse engineer" the loop. I get an immediate hit on personality types! (Uh, not that I'd want to imply that I map personality types onto an evolutionary scale!!!)

As for my "visual kick"--I am, actually, actively pulling together material on the role visualization plays in architecture, so please join Daniel in sending me links and ideas, anecdotes/experiences, whatever. I'm working on a presentation for a CAEAP event. My working title for the presentation is "PICTURE IT" but I'm also playing with 'Drawing People In" which has a double entendre that I like, given my message.

6/2/09: There's also an article on doodling on npr (March 12, 2009).

6/5/09: Here's an article on Powerpoint Design and visual thinking.

5/11/09 Orchesography

Every year, Bloomington has an Early Music Festival, and Weezie Smith is active in the program. At the recorder recital (where the kids and adults played a number of Renaissance pieces), she recommended Orchesography by Thoinot Arbeau. Written in 1587, it presents music and dances of the period. It has an interesting annotation for drum beats on the music score and an annotation for the dance steps, as well pictures of dancers showing the costumes and footwork. I remember Grady Booch mentioning a visual language for dance (labanotation) in one of his blog entries several years ago. Anyway, it fits my theme of visualizing--in this case using a visual language to create and record something that is inherently visual, but still hard to capture on paper without a language that is at least somewhat standardized to allow consistent interpretation. Last year I jotted some notes and thoughts on a similar topic--a language for origami. 

There are those who argue we have a language for expressing software systems, and it is the code, so we shouldn't duplicate the code with models that will just get out of sync as the code is adapted and evolved. Of course, architecture models aren't meant to be models of the code, but models of the architecturally significant structures (including dynamic models of the structures in action, under load, etc.). Yes, these will be built with code, but there is an important distinction between the architectural elements (services, components, mechanisms, ...) and the code that manifests these elements. For one thing, architectural elements are (largely) implementation language neutral (or at least, can be constructed using various languages within a genre). For another, they are important, in their own right, elements of design attention during initial design and during ongoing evolution of the system. They require thought, experimentation, testing/evaluation on paper and testing as constructed elements. That is, they allow for an important separation of concerns that supports designing systems that are "at once simple and complex" and which can be understood and built by teams of people working together as if of one mind to create a coherent system.

I read a blog post by Nick Malik that argues that agile architectures need about 10 pages of diagrams and nearly no supporting text. There are contexts in which that advice is good, but out of context I think the advice can be quite harmful. Models without supporting text need conversations to fill in for the missing text. Now you know that I absolutely value those conversations (and have deep misgivings about the setup in many IT shops where architects "parachute in" for the "architecture stage" and get pulled out before construction begins, to go parachute in on the next architecture assignment). But the text is still important! It takes considered attention to write up the rationale for decisions inherent in the models, and both the rationale and the attention are vital. So, orchestration is important here. There is a pulsing that needs to happen in concept formulation and maturation, as well as during construction--during the expansive idea-gathering phases, informal sketches and conversations with explanations and rationale jotted down by hand are quick and good for keeping the team fluid and the concepts malleable. During the convergent decision making phase, we extract the learning and make decisions and we need to be disciplined (but not exhaustive and exhausting) about recording the decisions and their rationale/justification/explanation and implications. Otherwise the lack of discipline mounts, until the task is just too big. These decisions become stakes in the ground--and it is easier to see when a stake needs to be moved than when it is just a mental marker someone has in his/her head that he/she may or may not remember to share with all affected.

This doesn't mean creating a 3lb "brick" to toss over the waterfall at developers! But minimalist is not nothing, and it is not just a few diagrams open to varied interpretations and reliant on repeated live explanation. The live explanations are important. So are architecture documents that are vivid with pictures and considered experience and rationale for the decisions they record and motivate. Vivid doesn't equate with long. And architecture documents aren't synonymous with waterfall.              

5/12/09 Stage-Gates

It is important in some contexts to recognize that for portfolio/investment and product and project management purposes we need points at which the system concept, then architectural design, then early functional deliveries, are mature enough to make bigger project-related decisions. But this doesn't mean we dispense with concurrent development and stakeholder participation, iteration and active learning about requirements and the structure that will best support them. We set out to fail fast and cheap, so that when we make our major investments in construction, they start out in a direction that makes sense for the market. Yes, we'll continue to learn and refine and evolve the requirements and architecture, but we're pointed in a high-payoff direction. 

Taking HelpMatch as an example, one workshop team worked with an operating model that included a physical warehouse/distribution center for donations. During ideation, you want to be able to assess options like that against other alternatives "on paper" without going to the expense of a physical trial! Other teams designed a system that matches offers and requests for donations. One team assumed that donors would look at requests, and self-select which requests to fill. These are not just operating model decisions, because there are substantial costs, challenges and risks inherent in the system that supports the different operating model alternatives, and the operating model is best considered with the these costs and challenges in mind. This means that even though the system concept stage-gate can still be a useful management construct, the activities that lead up to it include architecture work as well as market research and operating model formulation. But the architecture work doesn't have to be rigorous and can drop into logical and physical design views only as the architect needs to, to explore make-or-break challenges and risks.     

In short, we can map a highly iterative, agile process onto a stage-gate process, but we need to bear in mind that the stages should not be taken to imply functional islands of activity (marketing/requirements | architecture/design | construction | system test). Instead, the intent of the stages (set a target, refine and elaborate the target, build towards and refine, and possibly adjust, the target) is best met with an agile, concurrent development process and role design. For small teams and relatively simple systems, the process and role design that has been tagged "agile" is most effective. For more complex systems (for example, products with embedded software, or very large software systems, etc), more work may need to be done to enable several agile teams to work in parallel--as described in Getting Past "But." 

5/12/09 Testing on Paper

The other day an image of a dam wall design came unsummoned to mind, and it struck me how important it is in that case to "test" the design on paper. Yes, it is also thought about, communicated, and tested and improved with 3-D physical models, and computational models--but also just sketches. Of course I knew, but hadn't explicitly formed the thought in exactly these terms--that one of the things that designs do is enable us to test the design on paper. Oh yes, this is not the "be all and end all" of tests! But we are intelligent beings and we can use our imagination and experience to run thought experiments (this Einstein reference I have long used, as you well know). When we see an architectural drawing of a home we're having built, we can imagine doing the things we do in the spaces of the design. When we're designing a software system, we can use storyboards, yes, and also play out the collaboration among the architectural elements and weigh alternatives. And we can use these models to structure further analysis, for example creating stochastic models to better understand the scalability of our system.

This is all obvious, but it is one of those cases where the blindingly obvious blinds--all the "agilists" who dismiss models are dismissing this feature. The defects that carry the highest cost, are those that are the most strategic--relating to missed markets and major structural flaws. Every one of these that we eliminate cheaply through quick and dirty paper testing (and quick and dirty prototyping) is a big win, because discovering them when even a partially built system is already in place can be outrageously expensive.  

Models help us think, and models help us test our ideas cheaply, on paper even. And they create that shared group thought-space where we can collaborate on the design, and also have others help test our designs. This is what we mean with early validation of course--that has been part of VAP since its inception. But I think it makes a difference to say "test on paper". It is quick, it is crude. So to the extent that it allows us to find flaws and opportunities, and evaluate alternatives, it is cheap. Far cheaper than building even a slice of functionality--though it typically takes more than just a slice or two to learn the key lessons of system fit to context and design fit to purpose. The trouble with BDUF is that it sought to be right (with a stage-gate review but scant if any attention to conscious design stress-testing) and complete with the result that design documents were big and it took so long to do that the context was liable to shift, and it gave a bad name to doing any DUF. We don't want to go to exquisite detail on models that are just there to support thought experiments! Nor even to document the architecture decisions as they mature. Just enough. Not more. But also not less.

The architect has to use judgment, and one of the most crucial areas of applying judgment is in this area of what is enough, but also being careful to stay fluid and fleet and not rushing to cement initial choices in system concept and structural design. We have to put aside that frenetic code-is-all-that-counts schedule focus for a while, and be creative and investigative--explore possibility, opportunity, challenge and risk. To not do this, is to become locked in to our first ideas, and they are dangerous because they are the old ideas, the top of our mind ideas--in short, they are everyone's ideas because they are the easy ideas! Not exactly the ideas to differentiate upon! We have to, in Think Better terms, release the flood of ideas, let the tired old foregone conclusion set of ideas tap out, so we can get to the new, fresh ideas that will see us through the next epoch for the system we're creating.    

5/21/09: "Testing on paper" is much the same as "experiment on paper" and I've covered that notion in at least one earlier post (that, of course, is an understatement). It is useful, I think, to have both ideas in our "back pocket," because test speaks to some in our audience (perhaps those who are risk sensitive) and experiment speaks to others. Anyway, since I've been emphasizing the notion of thought experiments and crediting Einstein, I thought I should get better informed. According to the Psychology Wiki, credit should go to Hans Christian Orsted, who used the German equivalent of the term in 1820.

5/30/09: This may help make a case for JEDUF: Not so fast with that marshmellow...

5/12/09 Drive Convergence, or Lead?

Driver-driver types may prefer no-nonsense "drive convergence" wording--yes, "Drive in business terms is really a word for making something happen"--but it has a very dominance hierarchy/authoritarian flavor.

Collaborative types will find "drive" paired with "convergence" uncomfortable: People aren't cattle. We don't align people the way we align wheels on a car. And so forth. This is why "change management" was an unfortunate term--you don't manage change, or drive it; you lead change. (Outside consultants can't lead change in a client organization; the notion of change management consultants was flawed. Coaches they may be.)

We had the "with teeth" principle because we believe the architect needs to be empowered/given authority. But the architect who leads (a "from the front" image) rather than drives (a "from behind" image) recognizes that this is about the creation of systems in highly collaborative contexts.

Many architects have authority because they are viewed as authorities (meaning competent), not because they have formal power in an authoritarian, hierarchical sense... it is a "in the person" leadership quality rather than a "in the organizational hierarchy" quality. Of course, it is good if the formal organization supports rather than undermines the informal flow of authority, but the informal is powerfully effective.

5/12/09 Picture It

Sara asked me to "draw something, not just a stick figure." She wanted to see if I could still draw--I'm stung! But not because I think I can draw... No, I'm stung on Archman's behalf. Archman isn't (just) a stick figure!  He (and she) is a stick character. There's a difference. (I think. Maybe.)

Well... Tim Armstrong of Google draws even more primitive sketches than I do...

I have noted that Ryan draws the most amazingly accurate aircraft, fish, whatever, but all his people (even on the same drawing as an elaborately detailed machine or fish) are stick figures. Sara draws people with incredible accuracy down to the fingers and toes, and Ryan and I draw "stick figures." I wonder what that means? Grin.

5/13/09 Complexity

Modularity as a strategy for managing complexity is discussed in:

• The Architecture of Complexity, Herbert Simon, 1962
• Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code, by Alan MacCormack, John Rusnak, Carliss Baldwin, 2005

5/15/09 Pointers

Vijay Narayanan let me know that his article on building reusable services was published in SOA Magazine. Thanks for the pointer Vijay. You're paying attention to an important set of concerns in our field.

Adrian Grigoriu also let me know that the 3rd edition of his book on Enterprise Architecture is now in stores.

If you would like to suggest papers and books for inclusion on the Bredemeyer site, please do be sure to let me know, because it might otherwise take me a while to stumble upon them.      

5/15/09 On My List

Looking over Grady Booch's architecture and related books list, I realize I need to catch up on these:

• Ferguson, E. Engineering and the Mind's Eye. Cambridge, Massachusetts: MIT Press, 1994.
• Petroski, H. Invention by Design: How Engineers Get From Thought to Thing. Boston, Massachusetts: Harvard University Press, 1996.
• Petroski, H. Small Things Considered. New York, New York: Alfred A. Knopf, 2003.
• Petroski, H. The Evolution of Useful Things. New York, New York: Vintage Books, 1992.
• Sclater, N. and Chironis, N. Mechanism and Mechanical Devices Sourcebook. New York, New York: McGraw Hill, 2001.
• Pahl, G. and Beitz, W. Engineering Design. London, England: Springer-Verlag, 2005.
   
• Hubert, R. Convergent Architecture. Hoboken, New York: Wiley, 2002.
• Pastor, O. and Molina, Juan. Model-Driven Architecture in Practice, Springer-Verlag, 2007.
• Sessions, R. Simple Architectures for Complex Enterprises. Redmond, Washington: Microsoft Press, 2008.
• Spinellis, D. and Gousios, G. Beautiful Architecture. Sebastopl, California: O'Reilly Media, 2009.

• Taylor, R., Medvidovic, N., and Dashofy, E. Software Architecture: Foundations, Theory, and Practice. Wiley, 2009.

I found that our bibliography was seriously out-of-sync with our library, so I've put some cycles into updating that and still have more to do; way more!   

5/18/09 Hemingway on Minimalism

"If a writer knows enough about what he is writing about, he may omit things that he knows. The dignity of movement of an iceberg is due to only one ninth of it being above water." -- Ernest Hemingway, Death in the Afternoon, 1932 

Ryan read A Sea of Change, a biography of Hemingway, for his most recent book report. Given what Ryan learned about Hemingway's "iceberg principle" from the biography, he wrote:

"In The Old Man and the Sea, Hemingway uses a technique of writing in which only the necessary information is provided. He called it illustrating the iceberg." -- Ryan Bredemeyer, 5th Grade Book report, May 2009

Isn't "illustrating the iceberg" a great metaphor for (visual) software architecture? Talk about catchy names for principles!

Hemingway was clear that one shouldn't use this as a technique to mask what is not known, for that disingenuousness will be apparent; what is known and can be assumed to be known, can be left unsaid or sparingly said as we illustrate just the portion of the iceberg that we want to make visible. Minimalism and deferring decisions is an intentional strategy, but the intent is not to deceive. We need to know enough about the iceberg that we can illustrate the iceberg and have it float gracefully.

5/20/09 Organization Architecture

Researchers in the field of organization theory (organizational sociology including evolutionary theory, and organizational behavior including organizational learning) have looked at organizations as bundles of routines and capabilities (or competencies, in earlier work). Interestingly, organization theorists are looking at capabilities and architecture:

"The overarching objective would be to see how the architecture of the organization, including its divisional structure, transfer pricing, incentive policies, and socialization process relates to the architecture of its capabilities, in terms of both productive capabilities (how well it works a whole) and dynamic capabilities (how effectively it can change)."

Michael G. Jacobides, "The architecture and design of organizational capabilities," Industrial and Corporate Change, Volume 15, Number 1, pp. 151–171

and

"Organizations and their design, then, can be seen as different “shots,” different “bets” as for how to deconstruct complex tasks which, interdependent as they might be, cannot ever be carried out by a fully integral, entirely interdependent organization, due to the cognitive strain this would impose (Dosi and Grazzi)."

Michael G. Jacobides, "The architecture and design of organizational capabilities"

referring to Dosi and Grazzi, Technologies as problem-solving procedures and technologies as input–output relations: some perspectives on the theory of production, Industrial and Corporate Change, Volume 15, Number 1

5/20/09 Updates to Resources for Architects Books Lists

I updated the Visualization, Problem Solving and Creativity page on our Resources for Software Architects website--though there again I would need to do more if I wanted to sync up the page with what we have in our library--or even with what I like best of what we have in our library. Other Tufte books, at least one De Bono Mindmapping book, and Maeda's Simplicity book all come to mind as books I would recommend out of the larger set I've read.

5/20/09 Ok, Since No-one Else...

Did you notice this line in last month's journal:

Creativity needs a palette of more colors than black and white!

Isn't that inspired? You know, black and white--the color of code, of bulleted lists, ...

5/21/09 Architecture Journal--Call for SOA Papers

Microsoft's Architecture Journal is calling for articles on:

• SOA practices. Which ones determine the success-or failure-of a project?

• SOA governance. Running, monitoring, versioning: How better to serve services?

• To ESB or not to ESB. Angel or demon? When to consider it a fundamental piece? What about it should you get rid of? 

• From object to services. Considerations to guarantee separation of concerns after shifting paradigms. 

• Enhanced SOA. How alternative, complementary approaches such as Event-Driven Architecture (EDA), REST protocols, service virtualization, and others are helping SOA traverse the last mile of integration.

• SOA and The Cloud. What SaaS, S+S, and related emerging delivery models have to offer to an in-house SOA investment.

5/21/09 Illustrating the Iceberg

Grady Booch has been quiet of late, so I suppose the quote in his last blog post speaks volumes in an "illustrating the iceberg" kind of way:

"Any mind that knows itself also knows the body, which houses it, is decaying. It knows the end will come. And a mind forced to contemplate such emptiness is a force of rare creativity."

-- Bernard Beckett, Genesis, 2009

Randy Pausch, facing a ticking clock with not much battery life left, told himself: "Today is not the day." And with his Tigger-buoyant energy he made each day count, for himself, for his family and for all of us who received his legacy. When it is all done, on this project, on this step of our career, in this life, what will stand as our legacy? Uh... I have a book to write! Ciao!

Oh, speaking of Beckett, but a more famous one--Dana saw Waiting for Godot at the Theater Royal in London last week. And he saw Billy Elliott (the musical)! You don't even have to see me to know that I'm green with envy!

5/21/09 API Design

Daniel Stroe pointed me to an article in the latest Communications of the ACM that is a worthwhile read: "API Design Matters," by Michi Henning (May 2009).

5/23/09 Illustrating the Iceberg (from another angle)

Regret minimization, short tenure on this planet, all of these things are sobering reminders that if we want to do something big, something worthwhile, we better get on and do it. Outside in the peaceful dark last night, looking at the stars, I realized that my wellspring of motivation is not that ... uh... schedule pressure. It is joy. And I am so grateful for joy; for the joy of man's aspiring, creating, being in this world.

There is so much pain; evil and cancer that takes lives in hideous ways. Even when we live with awful realities remote to us, time runs its determined course through us. Like sea-sand through our fingers, it is futile to hold onto; besides there is pleasure in the pouring through. We human beings find joy in expansive moments, and awe-struck seeking is our grace.

The sword of Damocles notwithstanding.

5/25/09 Visualizing Panic!

I'm still on my visualization kick, trying to think about how to do my presentation at the CAEAP event conveying the power of drawing people in with pictures--by drawing people in with pictures... but I only have 20 minutes and some 30-40 people so not my usual cozy format where we can all draw around a sheet of paper. I watched Dan Roam's "Back of the Napkin" talk that he gave at Google last year. So Dan's all about pictures and he draws live right? No. Well, he highlights live, but he has his hand-drawn images all Powerpointed up in advance. That doesn't feel altogether aligned to me, but I'm sensitive to the logistical considerations...       

Dan Roam does make a great point along the lines of those that Sir Ken makes: ask a class of kids in kindergarten if they can draw, and all hands shoot up. Ask them if they can read and write, and only a few hands are raised. Then ask the same question of 16 year olds, and you get the reverse. We start out knowing how to draw, or at least being unabashed about our ability to visualize and render images, and it is educated out of us. So Dan has developed a strategy of getting people to draw a me="not very smiley" face right off the bat, to get past the blank canvas panic.

5/26/09: Enterprise architecture arose because the "divide and conquer" approach was leaving a bloody* mess... Alternatively put, a bunch of people have been feeling the proverbial enterprise elephant in the dark. Business people. IT people. Marketing. HR. Functional silos. Business unit silos. A way of seeing the whole elephant was needed.

And another bunch of people have been feeling the visualization elephant--engineering designs (from informal sketches to formal notations in electronics, software, etc.), process mapping, decision charts, graphical facilitation, etc. Those coming at the elephant from the business side posit a set of visualizations, and those from the engineering side another. Again, a way of seeing the whole elephant is needed.  

In just 20 minutes, I want to help people see the elephant. The whole elephant.

So they can draw the elephant.

Oh dear. I do seem to have a thing about elephants!

Well, I'm not the only one. A group we worked with (somewhat tangentially) calls their development process "the big elephant" because that is the shape their process diagram takes. They could draw an elephant, but realized we helped draw the elephant (rather than being relegated to trying to shove it from behind).

* Uh, sorry; that's rather too Monty Python, isn't it... I spent the past two days chaperoning fishing camp with three eleven year old boys. I told my son I'd rather he didn't spend quite so much time with his head in the toilet (figuratively) on one of the rare days I take off... Now here I am, using bawdy double entendre. I'm just so susceptible at this age. :-)  

5/25/09 How Does a Restauranteur Know So Much?

• Dilbert on ownership and failure

5/27/09 Only You and I

It occurred to me that when I talked about removing the lid, I did so in purely self-serving terms--I needed my memory crutch, and I expressed no gratitude or concern for everyone who'd taken to reading my journal as their late night soporific fix. The fact that I generally journal at night (unless I'm trying to catch a thought and pin it down), might have impacted this skew in my site visit stats. But more likely it was the soporific thing. So it was rather cavalier of me to discount those for whom my journal had become a habit. 

Please allow me to explain. I hope that people get value out of my writing. At the same time, though, I'm sort of incredulous that anyone would actually want to read this journal. So it is not that I discounted you, but rather that I discount myself... Moreover, I didn't realize that this would impact quite so many people, but the fall-off in unique visitors from late March to May was staggering. I just made the (entirely rational) assumption that there was my inner circle of architect friends who kindly show me undue forbearance, and a bunch of random others who were just one-stop-hopping, looking to see if this Ruth Malan person on the Bredemeyer site was someone to not take a class from, or something like that.

So, I do appreciate and thank everyone who reads here, and especially those who return here. Your hope that I might say something useful and interesting at some point, demonstrates a remarkable capacity for hope--that will stand you in good stead as an architect. Well, there it is--that useful and interesting thing you were looking for. Hope. For how can architects lead if they don't have an unstoppable belief in people, and their capacity to strive for, and sometimes reach, pinnacles of excellence?

And I do strive. Ad nauseam! Ciao!

5/27/09 Hand-drawn--Good Enough for Marketing

Well, well... I'm looking for a replacement scanner, and stumbled on Sharp's scan² page. Pretty cool! I just hope their system vision looked like that! Yours does, right?

My scanner lacks the "adjust the color/contrast/brightness so the background is light/white and free of artifacts" feature, so I've reverted to scanning in black and white, but it would be nice to be able to scan color sketches without getting paper grain noise and greyed backgrounds...

5/28/09 Reinventing Communication

• Reinventing Communication: A Guide for Using Visual Language for Planning, Problem Solving, and Reengineering by Larry Raymond
• Marketer's Visual Tool Kit: Using Charts, Graphs, and Models for Strategic Planning and Problem Solving, by Terry Richey

Anybody using LiveScribe? Do you like it?

I've tried a pen mouse and tablet PC and in both cases--nice idea, not there yet. Perhaps I happened on the wrong ones, so if you're using and liking either, please let me know. My drawing skills and handwriting are weak enough on paper, that I can't afford any deterioration through the drawing medium!    

Graphical recording/facilitation blogs:

• Nancy White (she casts herself as a graphical recorder, but she does also use graphic templates to facilitate sometimes)

I like this definition of collaboration that I stumbled on (by way of Nancy White):

 

Reinventing Archman? Three boxes and database feet... looks even more like conceptual architecture... hmmm...

Ahh, so Scott McCloud did the Google Chrome Comic. I don't think I noticed that when I first encountered it, but I should have known! I agree with the comment: "a masterpiece of software documentation." Scott points to an XKCD comic strip saying:

"Despite the crazed fantasy storyline, Tym is mapping the sort of intersecting, branching, and colliding paths that people in real life take all the time, but that only comics can make visible."

In my mind's eye, I'm forming a picture of this CAEAP presentation. ...tick... tick... 

Which reminds me, I'm enjoying Eugene Ferguson's Engineering and the Mind's Eye--thanks Grady. Well, I came by the recommendation indirectly, by which I mean it is on Grady Booch's books page--it's behind his login barrier, but it is well worth the entry effort to catch up on his architecture gallery, patterns catalog, and resource/references pages.

(Thanks to Scott, I spent some time with Bat for Lashes tonight; they have a pleasant musky sound. I'll have to follow up on more of the recommendations in Scott's post.)   

5/28/09 The Meaning of Life

(Dana is to be credited for the title of this piece.) There is a Machiavellian streak in many organizations and governments, and I don't understand why too many of our leaders have embraced meaning in the sense of being mean and diminishing people, rather than meaning in the sense of creating meaning, making life meaningful and uplifting. To understand, I might need to go back to two of the most influential books on executive and leadership reading lists: 

• The Art of War & The Prince by Machiavelli by Niccolo Machiavelli (Author), Henry Neville (Translator), W. K. Marriott (Translator)

But if one goes there, then another favored exec read pops onto the stack:

• The Art of War by Sun Tzu (Author), Thomas Cleary (Translator)

5/28/09 Handwritten Thank You Notes

I mentioned Weezie Smith and the inspiring example she sets, and I've mentioned Randy Pausch's handwritten thank you notes. Well, Sara drew a portrait of Weezie as a gift to thank her at the recital, but then she got frightfully shy and folded it up into a palm-sized wad before giving it to her. Weezie framed the portrait and wrote Sara a thank you note. Isn't that wonderful--seeing the shyness and responding so thoughtfully and kindly to it. Some people lead "the good life," and some people lead a good life. As for me, I just struggle with leading a life--with glimpses of what it would be like to lead a good life from paragons I encounter. In truth, I guess they struggle too, but are just more grace-full than I!

5/29/09 Experientially Thinking

Last month I watched Tim Brown (of IDEO) talk about creativity and play (video on TED), and I wrote:

Tim makes the point that "thinking with your hands," for example by building low resolution prototypes (e.g., using masking tape and children's clay), stimulates creativity. It helps to quickly get your thinking into the real world so you can test ideas much more quickly with users. We tend to think that because code is so malleable, and because we do have very productive prototyping languages, it is the best route to these early experiments. It is a good one! But therein lies the danger. We tend to overlook other "hacks"--a cereal box or storyboard, role play, pictures, brainstorm lists... Creativity needs a palette of more colors than black and white! Think "and."

I came back to that, because I was thinking about some of the "tools" on Dan Roam's visual thinking "swiss army knife"--in particular, "eyes, mind's eye, and hand-eye co-ordination."  The last seems a bit clumsily named; well, for my purposes, at any rate. Which is to say, I think that hands, or problem solving by building with our hands, is a critical creativity/innovation tool, and it does give us visual feedback on the tack we're taking in our mind's eye.

5/29/09: This one has some "functionally-foul language (meaning it works as emphasis in his dialog)": Rives Def Jam. It is astonishing! It makes me think we should teach children sign-language from preschool--to speak with the body that way, to be so expressive, is amazing. Of course, Rives is a performance artist, but I have to think the rest of us could be better communicators if we knew some of what he knows. It is often said that when we lose a sense, other senses intensify to compensate for those we don't have, but maybe the converse is also true--we don't develop our capacity for kinesthetic sense fully enough because we rely on our " five senses" and more traditional education-system-buoyed sense-making.

Researchers and leading educators have been directing our attention to opening up the learning box to visual learning and kinesthetic learning styles, allowing that some learners do better with those than verbal learning. Yet it seems to me that we need to develop these different styles in all; yes, some will be more peaked in one style than another, but: 

"a teaching strategy based on a ‘programmed learning sequence’ and designed to favor visually- and tactilely-oriented students increased attainment for all students in the experimental group."   -- wikipedia, kinesthetic learning

Now JPL and NASA and Boeing, before they will hire a research and development problem solver, even if they are summa cum laude from Harvard or Cal Tech, if they haven't fixed cars, haven't done stuff with their hands early in life, played with their hands, they can't problem solve as well.

-- Stuart Brown says play is more than fun (TED), May 2008

It occurs to me that it's not just in learning, but in creating, that we need to utilize these other modes of exploring ideas and solving problems. And I hypothesize that we can benefit from, and strengthen, these other problem solving styles by practicing them. And have more fun! 

Our brains are very effectively encapsulated. Well, Twitter is breaking some of that down, and people's thoughts are leaking out pretty much as they are formed... Sorry, couldn't resist leaking that thought...  Still, we need to speak, write, draw, use body language, build, to get our thoughts out of our heads so others can be influenced by them, understand them, interact with them, enhance or challenge them. Duh! Yes. But how often are we taken by surprise because we thought we got something out of our heads, but it hasn't influenced anyone else's thinking? Communication and collaboration are enriched by using multiple channels or styles--helping people to see what we mean through visualizations and tactile models, not just words. And inviting them to co-create the visualizations and tactile models, so they get actively involved in creating a shared group thought-space--on paper, in clay, or a role-play, etc.

Now I need to go oversee the disassembly of the defunct lawnmower, just in case Ryan or Sara ever want to work at JPL/NASA/Boeing...

5/31/09 Visualizing Data

Some examples of creative data visualization:

• GE's health visualizer
• Gapminder
  and Hans Rosling shows the best stats you've ever seen (TED), Feb 2006

"The eye can process information in the ratio of 12:3 times faster than the ear." -- structured visual thinking