A Trace in the Sand
Online Architecture Journal by Ruth Malan
I also write at:
Trace in the
- Why Be the First Penguin?
- Getting Time Back
- Compensating for Blind_Spots
- Blind Spots Take 2
- Sam Lowe
- Anna Liu
Other Software Thought Leaders
Um... and these
10/1/08 First, Your Co-ordinates
I read/skimmed (most of) The Back of a Napkin and if you've read/skimmed it you'll have the co-ordinates reference dialed in. But regardless, I just wanted to say, BEWARE — this is the undercover (read untrimmed; read long; read excess of everything—words, marginal indelicacy, whatever) version of my architects architecting architecture journal. If you're already gasping tl;wr (too long; won't read) by all means head for the surface version.
10/1/08 Getting Past "But": Innovation and Agile Architecture
We hope you will find time to take a look at our paper on innovation and agile architecture. Too often we hear "but architecture is about big design," and the converse "but agile doesn't scale." Getting Past "But" all began with this image of the architect trying to push the elephant (organization) from behind, and realizing we need to get the architect out front to lead. Pushing, whether it is string or elephants, doesn't work too well. That became an executive report, and it is now available on the Cutter site:
Ruth Malan and Dana Bredemeyer, 'Getting Past "But": Finding Opportunity and Making It Happen. Cutter Consortium Enterprise Architecture Executive Report, August 2008.
You can download a complimentary copy from http://www.cutter.com/offers/findopportunity.html
Well, I get to go back to Germany—Bavaria in early October is becoming something of an annual tradition. I do like my clients, and mountains! In the meantime, if you miss me, by all means track back through previous month's posts (left sidebar). I have joked that the Getting Past "But" paper will either put you to sleep or wake you up, so ... if it leaves you with a hankering for more on the soporific late night reading front, the "uncut" versions from preceding months are linked under archives in the left sidebar.
10/1/08 To Don't List
10/2/08 Change the Context, and the Way Power Flows
Dana has been watching Philip Zimbardo's TED talk, and shared this snippet: if you need to change a person, you need to change the context, and to change the context you need to change how power flows.
Part of what I want to get done with "Getting Past But" is, frankly, smuggling donkeys—change where architects are positioned in the innovation process. Get architects out front, where they can lead, rather than being set behind the elephant catching... um, being handed constraints dressed as requirements.
The locus of decision making is, frankly, a locus of power. It is worth being aware of this, even though it is generally distasteful for technical people to think about "power." It feels grubby and political. But systems are becoming so complex, the knowledge areas drawn on become so specialized, and what falls out is that decision making responsibility needs must be divvied up. Only, the way this is done is not always in the best service of creating a good, right, successful system where the voice of the customer, the voice of the business, and the voice of the development team, are taken into account.
Some architects have us come and work with their management team right off, for they get that changing the operating model starts with influencing the management team and often the management team looks to outside experts because they want that "cross-pollination," that learning from the lessons others have learned. Confucius said (quoted in The Opposable Mind—which I bought to read on my trip to Germany, but which I couldn't help dipping into):
"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."
Cynics may cast learning from others as imitation. But I'm not a cynic. On the blurb about our Software Architecture Workshop I said:
"Yes, there is some strength to the argument that architecting skills are learned from experience — but the lesson is always much less costly when it is from someone else's experience!"
(Of course, if anyone was going to put my wise words right next to those of Confucius, it had to be me... sigh... grin!)
With the "Getting Past But" paper I have tried to put a subtle tool in the hands of architects, a lever if you like, by which to start to shift management's perceptions about how to structure innovation teams and processes.
10/2/08 Why Should Anyone Be Led By You?
I've been reading Why Should Anyone be Led by You, and I like it. Of course, it makes a lot of giving recognition! Yeah! We like people who are like us, and I like authors who authenticate my message. (Goffee and Jones even make similar points about handwritten thank you notes.) Grin. [9/3/08] Of course, I feel totally redundant. ;-)
10/3/08 The Way to Become Wise
High on my "to don't" list right now is "scribbling" in this journal; to much to do. But this I can't resist:
i read article from your book name :software architecture:central concerns,key decisions".the book is titled software architecture action guide, by ruth malan and dana bredemeyer.
i am a student of IT. i am right now making an assignment of enterprise software architecture my topic for above subject is "in what way is enterprise software architecture different from system software architecture"
in this assignment i have to make comparision between enterprise software architecture and system software architecture.
i read some of books and articles online and i conclude that the difference between this two are in scope ,life cycle ,objectives, stakeholders ,strategy. but i am still little confused that how can i compare these with taking some examples. so can you please write me about this all with the relevant examples. so can you please help me out for making this assignment. reply as soon as possible. my assignment is due in short time. waiting for your reply."
Why does that strike me so? Well, of course you remember this line in The Wheel — quoted in "Getting Past But" so you have no excuses for not recognizing it ;-):
“Well, next to thinking, asking is the way to become wise."
Clearly this is a person on the route to becoming wise! Actually, the assessment of the difference between EA and SA is good, and the difficulty faced is real. So I pointed this person to the links page I maintain on the Bredemeyer Resources for Architects site with all the architecture case studies I come across. I do need to update that page, but it is a starting point. And if you publish a case study or come across any case studies in your reading, please do let me know, because this is an important page for all of us!
10/3/08 Opportunity Missed!
Hits on my site jumped radically in the last two days, following some networking of the "Getting Past But" paper (my thanks to those who have been passing the word around). That put me into a self-conscious and shy state, and I looked back over some "back-issues" of my journal to see afresh how people encounter me there. Surfing around, I was reminded that (drat) I didn't think to use these lines from my journal in the "Getting Past But" paper:
"All of this means architects are a key variable in the innovation equation. Set them at zero, and you get what you get—businesses clamoring for innovation on the one hand, or projects tanked out on unrealistic schedules, budgets and ambitions, on the other." [10/25/07]
My math, lit, comp sci and business backgrounds are so munged in those two sentences that I can't help liking them!
10/3/08 That Recognition Thing, Ad Infinitum
I mentioned Goffee and Jones (Why Should Anyone be Led by You), but I neglected to mention that these guys, as far as I can tell from the cover flap, are from the UK. Goffee and Jones note that giving and receiving praise is culturally hard to do in the UK. So, you really have to take them seriously when they talk about the importance of recognition and leadership. Yes, I do go on about the social side of socio-technical systems development, but I had to learn this the hard way too. I'm an introvert. I like being holed up inside my own head! Of course, many architects are introverts. And according to Goffee and Jones, most senior execs are introverts! I did not know that! So the point that Goffee and Jones make is that it is hard for introverts to do the social stuff of recognizing—you know, it means interacting with another person.
One point that Goffee and Jones make that really resonated with me, is that what followers look for from their leaders is a sense of significance. They want a sense of meaning, of purpose, and of having a role to play in achieving that purpose that makes the follower significant. Well, leaders aren't leaders if no-one is following, and people choose whether to follow. So if you want to lead, you need to do your part; make the people you would lead feel significant! Establish a compelling, shared purpose, give followers a significant role in achieving that purpose, and give them esteem-building feedback on their significant contributions to attaining that purpose.
I was thinking about meaning, and how art is distinguished from excellence in technique and execution by the meaning that we can find in it. And how the iPod, and products that hit that kind of high note, have a quality that goes beyond excellence in execution to a kind of fit to purpose and to context that has that "quality with no name" as Rechtin characterized it (and which I've tried to go after when I talk about delight). But I do wonder if that intangible zing has something to do with meaning, in the way that art that transcends technical excellence has something to do with meaning. It might be that it is a design cult thing that people identify with and the meaning comes from the group identity... [I'll have to think more about that, when it's not time to join the reading of 'arry 'otter... Yes, my kids, who had long baulked at Harry Potter the way they baulk at most mainstream/pop culture stuff, are now raving fanatics. Oh don't point at me—I bought them the first few Harry Potter books long ago, doubling up, as it turns out, on the first couple Dana had bought even before that, to read on a flight back from Singapore...]
10/3/08 What do Strings and Elephants Have in Common?
I was once working with some senior managers on an ambitious program and I just needed to get across that they needed to empower their architects to lead, and scanning for something, anything, to make my point in that moment pulled out the lace in my shoe to demonstrate that pushing string isn't effective. Pushing string, and pushing elephants have something in common. They don't work too well. Another time I was working with architects who were walled in by constraints they just couldn't get any stakeholder movement on, and I drew the elephant picture and told them from where they were, they may as well be given a shovel because all they could do was damage control. They have to stop saying "but" ("but this constraint," "but this stakeholder," etc.) and get out front and lead—find out what would align the stakeholders and get them moving toward a common purpose.
10/12/08 The Opposable Mind
My companion on my return flight from Germany was The Opposable Mind. I took these photos in a rose garden in Germany last week. They seem a good metaphorical fit for The Opposable Mind: seeing in the end, a beginning; the circle of life in the remnants of a rose.
Roger Martin's notion of an opposable mind is not a mind one can oppose, but a mind that is analogous to the opposable thumb—that has an evolutionary advantage over a mind that is not opposable. The unique property of an opposable mind is the ability to hold opposing ideas in constructive tension, to integrate what seems to be incompatible alternatives, to see past either-or options to an integrative solution.
The exemplars Martin studied:
• considered a broader set of factors and features salient to the decision;
• thought through more complicated causal relationships (nor just simple linear relationships); and
• viewed the decision holistically, keeping the whole problem in mind while working on the individual parts.
I am very excited about the applicability of The Opposable Mind to architects, and highly recommend it. [I read it, then Dana read my marked up copy and was frustrated that he couldn't read my scrawl which marks many of the pages. I interact with work that excites me, so my notes are "and notes" that integrate ideas and practices from The Opposable Mind into my thinking.]
The opening quote is quite relevant to the whole notion of getting past "but":
"The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function. One should, for example, be able to see that things are hopeless yet be determined to make them otherwise." F. Scott Fitzgerald quoted in the opening chapter of The Opposable Mind
Things may look hopeless, and we could cop out with "but." Yet we are determined to make them otherwise. On my last night in Germany, I watched Jean de Florette+Manon of the Spring, and there is this line that makes a certain kind of sense: "don't push a rock up a hill when you can accomplish your purpose by letting a rock roll downhill" (paraphrasing from memory). But you'd need to watch the movie to see the bigger moral context for this statement. If you're trying to do big things—good, right things—it might seem, sometimes, like pushing a rock up a mountain. That's because there is a lot of inertia wrapped into the status quo. I should mention, though, that The Opposable Mind is not about change management and vision. Still, it does make a strong case for reflection, and reasoning. In the airport, I was again barraged with IBM's "Stop talking start doing" ads, and again struck by this pandering to the popular notion that talking is counterproductive to doing. Yet thinking, reflecting, talking can all be part of doing—the part of doing that is "modeling out loud" in a team (in a team of 2 or 3, preferably), for example. Ok, so that's integrationist thinking—to make the case that we can talk and do, that we can design and have that be part of an agile process that is iterative and experimental. Indeed, that it is necessarily so, if we want to embrace the big mess of complexity that is the organic hotbed of innovation.
I'm sorry I took so long to get around to reading The Opposable Mind (Daniel Stroe recommended it months ago), but I am also glad I read it after I worked on the Getting Past "But" executive report. A note I wrote in the cover: "I'm either totally redundant or totally relevant!" Grin. Anyway, it makes me all the more confident about the exquisite relevance of The Wheel, and the brilliance of DeJong (its author)—wondering why, getting past de facto assumptions, and thinking about systemic interdependencies illustrate broadening the salience set, causal reasoning, and "decision architecture" (Martin's term) that are the heart of Roger Martin's model of the opposable thinker's process.
Well, The Opposable Mind is a quick read, and I do recommend it. Actually, it was such a quick read that I ran out of things to do on the plane trip (of course, it was a trans-Atlantic flight), and found myself watching Speed Racer...it's just not my cup of pop, but there was one tidbit of redemption: a standout line that translates to "architects don't become architects to drive, they become architects because they are driven." This fits with a key idea in Why Should Anyone be Led by You, which has to do with the sense of purpose that characterizes a leader.
[10/17/08] The Cutter copy editor pulled the quotes I used throughout the Getting Past "But" paper into the text, using bridge phrases to create flow. She was concerned that if the quotes stood out from the paragraph flow, the reader would tend to skip over the quotes. One of my reviewers made a similar point, so I accepted their call on that. The other side of the coin, though, is that other readers (like me), tend to read the quotes first—for example, the quotes that Roger Martin uses resonate with me, and indeed stimulated my interest in reading his book. Anyway, one quote I'm especially sad to see get tucked into a paragraph where it will only be encountered on close reading, is Howard Behar's principle "Think like a person of action, and act like a person of thought" (It's Not About the Coffee).
I should hasten to say that the Cutter editorial staff were fantastic; they went against their standard practice and let me keep my sketches, and they had only positive supportive things to say about my use of The Wheel, and the paper overall. That was important. I write (and teach) with the passionate purpose of helping architects navigate to right systems built right and I leverage all of my experience and all of my exploration into that. In presenting that to the world I feel utterly vulnerable, for one harsh reaction undoes a hundred kind, supportive ones. But equally, the next positive reaction puts me back in balance, restores my single-minded drive to help architects be great.
My notes from The Opposable Mind (no, I can't blame my writing on the bumpy flight).
10/17/08 Security Cartoon
10/17/08 The Power of Checklists
The neat thing about being on many peoples' contact list, is that from time to time I get an email that was not intended for me but which reaches me serendipitously. Today I got such an email from someone in a workshop last year. Because I knew the sender, I opened the email and was perplexed to find it had just two links, one to a healthcare blog. I was intrigued enough to follow the link to the blog to see if my workshop alum was the blogger. And so it was that I came to read this blog post and this article on checklists. It is long, but it is a great analogy and motivation for developing checklists in architecture. The serendipity was all the more astonishing because a checklist for architects was suggested by Salman in the workshop just this past week. It was exciting to stumble so by chance upon exactly the story that makes a powerful case for checklists in the face of complexity!
[10/20/08] Salman was suggesting that something like ACID, but for architecture, would be useful. Ok, let's take Grady Booch's guidelines:
That spells SCARS! How appropriate (you know, it's what you get from experience)... Grin.
I have been asking architects to create a table (derived from work done by Charlie Alfred, who, you'll recognize, is one of my heroes) with a column for each of:
This is intended to be a radar that helps the architect (or architecture team) think about what, at this extraordinary moment, is the most important thing he/she should be paying attention to (a la Bucky Fuller). During early iterations, the priority is a forcing function for the architects—forcing them to step back and consider the bigger context of the system value, and what it will take to build it, and what is make or break for the system overall, and make or break for the architecting effort at this point in the process. What we are paying attention to shapes what we pay attention to—that is, unless we have forcing functions like this to get us to take a step back (or to the side) and think about what if and what else.
The first came directly from The Wheel, and the second and third spun right out of its direction to think about the system context, the ecosystem if you like, and the interdependencies (what else), and to break down preconceived notions and confining assumptions (what if). I relate these to broadening the salience set and causal reasoning that are the heart of Roger Martin's model of the opposable thinker's process (The Opposable Mind).
10/18/08 Empathy and Leadership
Empathy is a trait of resonant leaders. We teach our kids about the "Golden Rule." "Think like a stork" and "walk two moons in another man's moccasins" are important empathy principles. Are you an empathetic leader?
In Why Should Anyone be Led by You, Goffee and Jones make the point that there are various leadership styles, and the style of a leadership icon may not be anything like your style. The fact that you don't match a given leadership icon's style (say, for example, Jack Welch), doesn't have any bearing on your leadership potential or, necessarily, on your leadership development path.
That said, empathy is a powerful and useful trait. And it can be practiced. We can use empathy to find opportunities to create value (developing better requirements), to make tradeoffs that factor other perspectives not just our own, to develop rapport, to give feedback, to lead.
In the last workshop, a couple of architects objected that the architect, in their experience, is not a leader. It could simply have been a confusion of terms, and we did discuss the role of project managers versus architects, and formal authority versus leadership and influence. The architect as the solver of tough problems, the call guy when there is a crisis at go-live, does not have to be a leader so much as a smart, experienced technologist and system thinker. Still, the architect as the person of ultimate accountability for right system built right absolutely has to be a leader—if the system is complex enough to require that many heads and hands create it, that is.
That is not the same as saying the architect dictates, or drives (although the lead architect of a very effective architecture team was appointed by the team of peers to be a "benevolent dictator'). No, but the architect does (need to) lead.
"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
Robinson's talk is right funny! Thought provoking too. Dana recommended it to me, and I'm passing the recommendation on to you!
10/20/08 Getting Time Back
Dana has downloaded a bunch of the TED talks to his iTouch to watch on trips. One of the architects in the last workshop recommended downloading books from Audible to listen to while commuting to work. Dana also listens to audio books when he's cooking, working out, driving, flying and waiting, and waiting, as one is want to do, when one has to fly. These things sound so obvious, but sometimes the obvious is hidden—you know, the blindingly obvious that blinds. When one is finding ways to get time back, especially to read (or be read to), the little overlooked ideas can come in very handy. You know, there's only so much you can cut back when it comes to cleaning the toilet... ;-)
But... I still like to read dead trees, mainly because I like to mutilate what I'm reading, bleeding my thoughts all over the page. Or something macabre like that.
10/21/08 Compensating for Blind Spots
I've started reading Visual Thinking for Design, by Colin Ware. He references a study by Mack and Rock, who coined the term inattentional blindness:
"The phenomenon of not seeing things that should be obvious is called inattentional blindness."
Ware is mainly focused on visual perception and attention related to seeing, but we see the same "limited attentional capacity" (Ware's term) in how and where we pay attention within other areas of cognitive complexity—architecture, for example. Which is why I have been encouraging architects to keep a visual radar of value/capabilities and associated uncertainty/challenge/risk. Early on, we should expect to have a lot of uncertainty around value propositions. If we don't, we're not being innovative, not stretching ourselves and our innovation team to get out of the box of our preconceptions! The funny thing is, time after time, something highlighted as an area of uncertainty or risk at one pass, is simply taken as a given at the next pass, and never revisited. So we have to have mechanisms to help us get out of the rut of our predilection for making forward progress at any cost.
This predilection is so very strong that we even persuade ourselves that Agile and Scrum can scale without up-front design. But what does this mean? We don't really place value on getting competing options on the table. We grab at the first fruit of the low-hanging variety, and start to put working code in front of users to get onto the path of necessary evolutionary adaptation. The problem is, where we start then becomes the best predictor of where we'll end up, because anything other than a tune-up is just too costly. The whole thing is self-justifying! Instead of forcing ourselves to put 5 different options on the table and think through the why's, what if's and what else's, we go with the first thing and let the market tune us up or tune us out.
Now Einstein used thought experiments as an explicit tool to expand our field of knowledge. Ok, so we're smart, you and I, but we're no Einstein! So we can dispense with his thinking tools, right? That's the natural conclusion, isn't it? No? No! Ok, so thought experiments are a useful tool in our toolbelt, and they fit a whole lot more problems than we typically give them credit for! The answer to scaling Agile and Scrum is not to flail architecture with the BDUF whip, but rather to apply that integrationist skill that distinguishes good systems thinkers, and apply agile, iterative, incremental to architecture—or Just Enough Design Upfront (JEDUF)—and apply JEDUF to scaling agile, iterative, incremental development. Of course, if you've read Getting Past "But," you'll recognize this message.
The brain compensates for the blind spot in the eye (where the optic nerve and blood vessels enter the eye) by scanning. We need to compensate for our mental blind spots with rapid scans of the systemic picture—the value context, the business context of the business sponsoring system development, and the (technical) system context, and the system design and its fit to context and to purpose. So, we need to develop a generic architecture checklist of the fundamentals (taking Booch's SCARS as a starting point) to make sure we don't ignore something fundamental, and for each system we need to create a system-specific checklist that gets us to pay attention to the big uncertainties, challenges and risks that we would otherwise sweep under the rug of "forward" momentum. "Develop alternative system concepts" should be way up there on the checklist, but we tend to think that is just too expensive, especially since we're going to embrace evolutionary development. We just have to recognize that what we put in place starts to shape what users expect, so we have a tendency right off the bat to tinker and tune, rather than to look for the "delight" solution that may even cost less! So we become vulnerable to a competitor's alternative approach that is much better than a tune-up from our starting position. The cost of this approach may not be so readily apparent, especially if we have a captive audience. Until it is devastatingly apparent.
This may all sound obvious. But team after team trips up on exactly this predilection to start down the path of progress without questioning the path. It is self-reinforcing. What we deliver shapes expectations. Our software interacts with and shapes the world around it. What we pay attention to shapes what we pay attention to. And all of a sudden an Apple comes out with something that seems both radical and not, that just puts together the "obvious" (hindsight being 20-20) in some novel way.
Visual Thinking for Design (Colin Ware) starts out with a great story about an experiment that is like the basketball and gorilla experiment that Temple Grandin shares in Animals in Translation. In the experiment Ware recounts, passersby are asked for directions on a map. Two people carrying a door pass between the direction seeker and the direction giver creating a distraction, and the person asking directions is switched. More than half of the persons giving directions don't notice the switch, even though the person is dressed differently and has different hair color. Even when the substitute direction-seeker is of the opposite gender, most of the people randomly included in the experiment did not notice the switch!
What we are paying attention to, shapes and filters what we pay attention to. I see this over and over in workshops, but that is an artificial environment which can be muddied by the fact that some people are just trying to get the exercise done... My sensitivities around this matter got raised seeing the same thing happening on architecture projects where (a sizable chunk of) the business is at stake! We have to be willing to fail, but it is not ok to fail with a $4 billion price tag. We need to fail fast and cheap—alternatively put, we need to fail through experimentation, much more than we fail through the hard test of fielding and fielded systems. And to the extent that we can posit and test alternative approaches and system concepts with thought experiments, so much the better! All this with the caveat that we do need to time-box all this experimentation. We have to create a balance between no experimentation and too much, analysis and paralysis. Zero is too little. Even for complex, larger-scale systems, six months is, generally speaking, too much. When we let this play out too long, "stop-talking-start-doing" antibodies begin to mass. Antibodies exist to protect against past ills, so they are there for good reason. We need to strike a balance. It's not all-or-nothing or either-or. It is "yes, and." Opposable thinking. Thinking resistors will oppose, but thinking that allows evolutionary advances leading to evolutionary advantage.
10/22/08 Lessons From Path Finding Applied to Software
I just had to share Charlie Alfred's response as it is an insightful contribution to this discussion:
"Here’s a thought on your “Compensating for Blind Spots” post. You correctly observed:
The problem is, where we start then becomes the best predictor of where we'll end up, because anything other than a tune-up is just too costly. The whole thing is self-justifying!
This reminds me of a problem we faced when part of a start-up doing transportation routing and scheduling software in the mid 1980’s (geez, does this make me feel old). We were trying to come up with a heuristic that could produce satisfactory solutions to the “traveling salesman problem.” What is the shortest path to visit each of several geographic locations?
We performed our own little thought experiments, certainly nothing that would impress Einstein. But even simple thought experiments can be powerful ones if they shine some light on hard to visualize problems.
What we did was very simple, and would be easy to try by anyone:
Replicate this grid twice.
On the first grid, start at the “H” and draw a line to the nearest “X”, then go to the “X” closest to that, and continue until all the “X’s” have been reached, then draw the final line segment back to the “H”. The blind spot of this heuristic is that it frequently leaves outliers until last, when they are often the furthest from where you are.
On the second (copy) grid, use a different heuristic. At any point, find the “X” that is the closest to that “X” and furthest from “H”.
This heuristic tends to look for the best opportunities to handle the outliers.
For example, suppose you are at point X1, which is the closest one to an outlier X2. Two other points, X3 and X4 are both closer to X1 than X2 is, but they are in the opposite direction. The closest point heuristic handles “low hanging fruit” but takes you further away from the troublesome outlier. By contrast, the “closest to X and furthest from H” heuristic encourages you to swoop out and handle X2 while you aren’t too far away from it. X3 and X4 will still be there for the taking on the way home.
I suspect that this routing and scheduling experience has subconsciously impacted my approach to architecture. Figure out how to identify the tough challenges (i.e. the outliers) and make sure to figure out how to attack them. You might not design or code the solutions to these challenges first – there may be any number of other dependencies that you must address first. However, while doing this other work, you always keep the intended approach to the tough problem in mind, to avoid painting yourself into a corner.
The reason this analogy works is that a driver’s route is an interdependent set of stops. The decision you make about X1 affects both what you do next and the overall result. Software architecture is the same way."
Charlie Alfred, personal email, 10/22/08
I mentioned Sir Ken Robinson's talk at TED, and though it ostensibly speaks to educating our kids for the future, it has implications for us today. I was marveling at how the human brain has evolved over millennia of incremental change, yet has managed the unprecedented informational complexity explosion of the past 60 or so years. In every field of endeavor, humankind has made extraordinary advances at an ever accelerating pace (at least so it seems to me). Now, Ken Robinson asks us to think about our kids 60 years out, and what they'll be facing and it is mind-boggling. So he challenges the education system not to squash creativity in children.
We equally need to challenge ourselves. Yes, we have been extraordinarily creative, despite the damping forces of our education. Still, the world is becoming ever more complex, and this complexity drives up the need for integrationists, for system thinkers, for bridge builders (Charlie Alfred's conceptual distance and complexity essays come to mind, of course). So, we are seeing more and more encouragement and challenge to integrate visualization and emotional intelligence into our work-life. We haven't worked much on integrating the dance and work thing, though we are being encouraged and challenged to see leadership as a performance art... Grin. If you didn't already watch Sir Ken's talk, I do encourage and challenge you to. Grin. [The challenges I put to you, ad infinitum.]
At a minimum, there's some great jokes—like, you know the one that starts "if a tree falls in a forest, and no-one hears it"? Well, Sir Ken says he saw a t-shirt with "If a man speaks in a forest and no woman hears him, does that still mean he's wrong?" I mean, you just have to listen to a talk that finds a way to work in a joke like that. Grin. In fact, that inspires me—I've set myself a challenge to take 5 or so really good jokes and structure my workshop introduction around them. That would be creative, am I right?
Actually, Sir Ken has this style of apparent stream-of-consciousness joke telling, but he is skillfully weaving the themes that make his message compelling. It is quite instructional watching him. And compare his talk to Jeff Bezos' talk. I liked that too. But Sir Ken holds our attention through self-deprecating wit, jokes, and stunning conclusions. No Powerpoint. Not even any "drawrings." [Sorry. Couldn't resist. It's so cute!] And the drawring joke is great, and it works for architecture too—you know, when you're sketching your architecture live, you can tell the joke and follow it up with "but no-one knows what the system will look like" and "they will in a minute." And then you can talk about the setting in which the joke is told—the setting being a child's willingness to take a shot, to be wrong, and set your audience up to give you input because you have shown boldness in taking a shot, but also humility and a willingness to be wrong.
Ah well, maybe not. I take risks like that, and you see where it gets me...
10/22/08 Innovation and Fundamental Research
10/23/08 Compensating for Blind Spots—Take Two
Let's consider HelpMatch. One approach is to match need to help through stories, so the need is expressed in a coarse-grained way, and the story is what compels the helper to go the extra distance in collecting and personalizing the help. Another model is to create a virtual warehouse of offers for goods that needers can select from, rather like an online shopping model. Another model is to create a virtual inventory of offers and a virtual inventory of needs, and the system does the matching using some matching, prioritizing, and fairness algorithm. Each of these can be implemented by several different system architectures. Quite quickly, the space of business model-system model possibilities gets interesting and there are significant differences among them. Yet in workshop after workshop, teams jump on one obvious (to them) option and get locked in to a completely unquestioned assumption that the business model-system concept pairing they're fleshing out is the "right" one.
The immediate push-back I get when I point out other options, is that it is unfair to set such a problem because the "business team" should have figured out the operating model in advance, and the architects should only be asked to design the information system that supports the given operating model. That breaks the basic tenet of architecting! If we recognize that business systems and information systems are interdependent then we recognize wherever we can, we should design across them. The architect, as the person on the innovation team with deep technical roots but an aptitude for thinking systemically, should be helping to think about the operating model and the system that supports it. There is no a priori perfect operating model, meaning perfect without considering the interdependencies between the operating model, technology, and context—we achieve good fit when operating model and what technology makes possible are considered together not just with the current context, but the way the context will be reshaped once the system is in place.
That's a challenge, especially since we come from a background of developing pieces of a system, thinking through algorithmic steps, sequential flow, and being responsible only for the product of our own head and typing speed. We have to get ourselves out of that next step mentality, and that's why Charlie Alfred's value-challenge-strategy matrix created a great big ca-chunk in my mental models, and a whole lot of things came swooping into a new alignment for me. If that sentence was altogether too Harry Potter'ish for you, let me just say: I started advocating using the value-capability-uncertainty/challenge/risk-priority/urgency radar to refocus architects, to be a forcing function that explicitly makes us open up to new options and alternatives. How does this work? For each uncertainty, we need to explore options. For each challenge, we need to explore options. Etc. You get the point. To do this at all convincingly, we simply have to explore on both sides of the operating model-system model boundary (and later the use concept/user experience design—system structure boundary). And we have to think about what if and what else, and wonder why—for example, why do the current offerings on the market miss the mark?
Yes, ultimately we'll get to scan our experience and the collected experience of our field for patterns to address key design challenges. All that good stuff. But no mechanism design matters a sconce if the overall approach is off-target, meaning a competitor is going to come up with an approach that much better fits user needs and values, and addresses their concerns, frustrations, desires, aspirations, cost sensitivities, etc.
So the problem starts big picture, and the same perceptual flaw, the same grab-a-low-hanging-fruit-and-run-with-it tendency, happens over and over as we delve into the architecture. You know, we're so focused on giving those directions, we don't even notice when the person asking for them is switched...
Ok, so this line is your ticket to getting past "but" (for example, "but the CEO has told us to create a system that does X and uses technology Y," etc.):
"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
Isn't that a great strategy—to try to be wrong? Yes, to try to come up with the "right" problem/solution pairing given the CEO's preconceived notion of what the "problem" is, and even what his notion of the "solution" is, and also to be as creative as you can in coming up with "obviously" "wrong" problem/solution pairings! Trying to be wrong yourself is a much more palatable alternative than trying to prove someone else wrong! But it puts more axes of variability on the table. How much does this cost? A day, or even a few days. Compare that to fielding your CEO's version, and having the market decide... If it is the only option, well, that will shape expectation and be a self-fulfilling prophecy of success. But how likely is that, in a world that is exploding with options?
Ok, so I my son just asked me to help him look for an airplane he misplaced. I told him to "look where it could be and where it could not possibly be," including where he has already looked in case he overlooked it. Know what he said (exasperatedly)?
"I don't need you to say stuff that I can think faster than you can say!"
That has to be a line to go down in history! What a line to cap all that I have been writing here these past few days!
You know, I think he's going to be a software engineer. Grin. I was that smart once too. Sigh.
[10/24/08] Charlie returned with his special brand of insight wrapped in humor (Charlie can take Sir Ken Robinson on any day!):
'I got a laugh out of Ryan’s comment. I can’t count the number of times that I have heard something similar from my own kids, or even at work. The number is high enough, that I’ve given it a name:
Outcome Over Process
[Those] who play the “Outcome over Process” game are not interested in getting better, just adding achievements to the score card (status report, bonus check, etc.). “I already know how to play golf. I just want to shoot a good score today.”
Ryan wants the missing airplane (outcome) and doesn’t really care how (process). This is an example where:
The corollary to “Outcome Over Process” is:
Procedure over Insight
“Just give me a good way to get this done, don’t clutter my brain with a set of conditionals and hypotheses to consider so that I can adapt to changing conditions.” '
Charlie Alfred, personal email, 10/24/08
I read Ryan's line and Charlie's response to Dana—he got his daily dose of heart-healthy laughter in one capsule right there! And I got good parenting advice as a bonus—if I'd just agreed to find the plane I could have a commitment for a few days of grouch-free piano practice, if not $5! You just have to know where the levers are. Silly me!
10/23/08 Visuals for Thinking
Today I bought and read a good deal of Making Comics and Reinventing Comics, and I'm just getting into This is Your Brain on Music. Yes, I'm in a life resuscitating plunge into other people's thinking after hearing my own voice way too much the last two weeks, ... and facing more of that next week.
This is Your Brain on Music was recommended by one of the architects in the workshop in Germany. You no doubt remember my Valentine's Day homage to architects? Well, thank heavens for architects and what they teach me—about systems and architecting, about myself (ouch, ouch, ouch and... ouch), and life.
Have you seen Indexed (the book) and ThisIsIndexed (the blog)? Jessica Hagy has a neat formula, and it emphasizes the power of simple sketches, juxtapositions, Venn diagrams, axis choices, and being more conscious of the state of the world, perception, and relationships, and the power of more than my "must-get-the-kids-to-bed" brain is capable of coming up with just now.
10/24/08 Modeling Tool
Brian Burrows brought EDraw Max to my attention, saying "It may not be a replacement for Rational, but it has the wow factor executives love to see in conceptual architecture." Thanks Brian.
I know it jars with technical purists that we have to "sell" the architecture, that we have to sully ourselves with "marketecture." * I first came across that term marketecture in Luke Hohman's book, but Sheldon also brought it up last week as something his group explicitly pays attention to—bravo, I say. The thing is, if you're leading a group of technologists, you have their hearts and minds, their passion—ok, their work—riding on your ability to get and sustain sponsorship. No really, success—technical success—is your charter, but to get there, the system has to see the light of day. It has to survive everything else that competes for budget and attention. ...And then it has to survive the test of the market. Market failure is bad, but even market success is tough on systems and their architects—you don't want to be a victim of the blame bus, whether for scaling issues, or spaghetti.
So, marketecture. I mentioned I'm reading Making Comics and Reinventing Comics. Partly it is just to think about some fun ways to get points across—"up and out" marketecture stuff, as well as in the developer community. And McCloud does a good job talking about communication, clarity, simplicity, etc.
Speaking of modeling and tools, what are you hearing about Microsoft Oslo and D?
* Diminishing the importance of the role of "right system" (not just built right) isn't just an issue in software; Martin Fowler's wife, a structural engineer, reportedly has said building "architects are good for the three B's—bulbs, bushes, birds." You could see a strictly technical expert making the same quips about the kind of architect who takes on advocacy for (if not ownership of) right system built right. So, mainly, it depends on what you believe in. Is architecture just about "built right" or is it about "right system built right?" In this nascent stage of our field, how your role is shaped depends a lot on you—what you believe about the role will determine what you do, and it will be a self-fulfilling prophecy.
One client group I worked with this past summer has created the role of "functional architect" and "technical architect" and I relate this to "building architect" and "structural engineer" in the building industry. But in the software case, the "functional architect" oversees system design from system concept (the customer/business facing view) through conceptual architecture, and the technical architect takes over to design logical and physical/execution architecture. This has the drawback that no one person has full lifecycle accountability for the architecture, and the iteration between conceptual architecture and logical and execution architecture (and system construction through the various architecture decisions/views) isn't clearly led by one ultimate technical decision maker. The upside, though, is that you get functional architects who really embrace the architect's strategic value finding/value creating role—the right system dimension of right system built right.
10/31/08 Trick or Treat?
One of the architects in the workshop this week pointed us to Shift Happens.
I removed the photo of the ...shift... being cleaned out of the elephant, because:
i. I don't know who to credit it to, and
ii. one can chuckle in private about the potential relevance of the photo not just to our job but to politics... Still, in the wrong hands that photo would be about as tasteless as a political effigy.
10/31/08 Fit to Purpose and Fit to Context
Architecture is about ensuring that the right system is built, and it is built right. It encompasses decisions that have the highest cost of change. And decisions that have high strategic impact. Architecture is about creating value and about addressing the challenges and risks that come hand in hand with creating value. "Right system" is about fit to purpose and fit to organizational and use context. Alternately put, the architect needs to listen to the voice of the customer and the voice of the business, the voice of the user and the voice of system operators, the voice of marketing and the voice of developers.
Seth Godin makes the point that the messages that create market pull for our products need to be remarkable. And Yves Behar makes the point that products with remarkable designs (not just "pretty skins," mind) sell themselves—advertising is the price we pay for poor designs. Seth Godin suggests that products don't have to be excellent, only remarkable. Well, he may be right. But that's depressing! Wouldn't we rather create products that are remarkable for their excellence on key differentiating dimensions—for creating a sense of delight, a sense of goodness of fit, a sense that the product or service is the way customers would like it to be?
10/31/08 Happy Halloween!